* [PATCH][gdb/breakpoint] Fix assert in jit_event_handler @ 2021-05-20 15:29 Tom de Vries 2021-05-20 16:22 ` Simon Marchi via Gdb-patches 0 siblings, 1 reply; 7+ messages in thread From: Tom de Vries @ 2021-05-20 15:29 UTC (permalink / raw) To: gdb-patches Hi, Consider a minimal test-case test.c: ... int main (void) { return 0; } ... which we can compile into llvm byte code using clang: ... $ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c ... and then run using lli, which uses the llvm jit: ... $ lli test.ll ... If we run this under gdb, we run into an assert: ... $ gdb -q -batch -ex run --args /usr/bin/lli test.ll Dwarf Error: Cannot not find DIE at 0x18a936e7 \ [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". src/gdb/jit.c:1178: internal-error: \ void jit_event_handler(gdbarch*, objfile*): \ Assertion `jiter->jiter_data != nullptr' failed. ... This is caused by the following. When running jit_breakpoint_re_set_internal, we first handle libLLVM.so.10.debug, and set a jit breakpoint. Next we handle libLLVM.so.10: ... (gdb) p the_objfile.original_name $42 = 0x2494170 "libLLVM.so.10" ... but the minimal symbols we find are from libLLVM.so.10.debug: ... (gdb) p reg_symbol.objfile.original_name $43 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" (gdb) p desc_symbol.objfile.original_name $44 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" ... and consequently, the objf_data is the one from libLLVM.so.10.debug: ... jiter_objfile_data *objf_data = get_jiter_objfile_data (reg_symbol.objfile); ... and so we hit this: ... if (objf_data->cached_code_address == addr) continue; ... and no second jit breakpoint is inserted. Subsequently, the jit breakpoint is triggered and handled, but when finding the symbol for the breakpoint address we get: ... (gdb) p jit_bp_sym.objfile.original_name $52 = 0x2494170 "libLLVM.so.10" ... The assert 'jiter->jiter_data != nullptr' triggers because it checks libLLVM.so.10 while the one with jiter_data setup is libLLVM.so.10.debug. This fixes the assert: ... jiter_objfile_data *objf_data - = get_jiter_objfile_data (reg_symbol.objfile); - = get_jiter_objfile_data (the_objfile); ... but consequently we'll have two jit breakpoints, so we also make sure we don't set a jit breakpoint on separate debug objects like libLLVM.so.10.debug. Tested on x86_64-linux. Any comments? Thanks, - Tom [gdb/breakpoint] Fix assert in jit_event_handler gdb/ChangeLog: 2021-05-20 Tom de Vries <tdevries@suse.de> PR breakpoint/27889 * jit.c (jit_breakpoint_re_set_internal): Skip separate debug objects. Call get_jiter_objfile_data with the_objfile. --- gdb/jit.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gdb/jit.c b/gdb/jit.c index 296b436c796..be10f197fd6 100644 --- a/gdb/jit.c +++ b/gdb/jit.c @@ -807,6 +807,10 @@ jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, program_space *pspace) { for (objfile *the_objfile : pspace->objfiles ()) { + /* Skip separate debug objects. */ + if (the_objfile->separate_debug_objfile_backlink != nullptr) + continue; + if (the_objfile->skip_jit_symbol_lookup) continue; @@ -833,7 +837,7 @@ jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, program_space *pspace) } jiter_objfile_data *objf_data - = get_jiter_objfile_data (reg_symbol.objfile); + = get_jiter_objfile_data (the_objfile); objf_data->register_code = reg_symbol.minsym; objf_data->descriptor = desc_symbol.minsym; ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler 2021-05-20 15:29 [PATCH][gdb/breakpoint] Fix assert in jit_event_handler Tom de Vries @ 2021-05-20 16:22 ` Simon Marchi via Gdb-patches 2021-05-20 22:04 ` Tom de Vries 2021-05-21 11:27 ` Tom de Vries 0 siblings, 2 replies; 7+ messages in thread From: Simon Marchi via Gdb-patches @ 2021-05-20 16:22 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 2021-05-20 11:29 a.m., Tom de Vries wrote: > Hi, > > Consider a minimal test-case test.c: > ... > int main (void) { return 0; } > ... > which we can compile into llvm byte code using clang: > ... > $ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c > ... > and then run using lli, which uses the llvm jit: > ... > $ lli test.ll > ... > > If we run this under gdb, we run into an assert: > ... > $ gdb -q -batch -ex run --args /usr/bin/lli test.ll > Dwarf Error: Cannot not find DIE at 0x18a936e7 \ > [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug] I guess that's unrelated, but do you know if that error is a sign of something wrong in GDB? > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > src/gdb/jit.c:1178: internal-error: \ > void jit_event_handler(gdbarch*, objfile*): \ > Assertion `jiter->jiter_data != nullptr' failed. > ... > > This is caused by the following. > > When running jit_breakpoint_re_set_internal, we first handle > libLLVM.so.10.debug, and set a jit breakpoint. > > Next we handle libLLVM.so.10: > ... > (gdb) p the_objfile.original_name > $42 = 0x2494170 "libLLVM.so.10" > ... > but the minimal symbols we find are from libLLVM.so.10.debug: > ... > (gdb) p reg_symbol.objfile.original_name > $43 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" > (gdb) p desc_symbol.objfile.original_name > $44 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" > ... > and consequently, the objf_data is the one from libLLVM.so.10.debug: > ... > jiter_objfile_data *objf_data > = get_jiter_objfile_data (reg_symbol.objfile); > ... > and so we hit this: > ... > if (objf_data->cached_code_address == addr) > continue; > ... > and no second jit breakpoint is inserted. > > Subsequently, the jit breakpoint is triggered and handled, but when finding > the symbol for the breakpoint address we get: > ... > (gdb) p jit_bp_sym.objfile.original_name > $52 = 0x2494170 "libLLVM.so.10" > ... > > The assert 'jiter->jiter_data != nullptr' triggers because it checks > libLLVM.so.10 while the one with jiter_data setup is libLLVM.so.10.debug. > > This fixes the assert: > ... > jiter_objfile_data *objf_data > - = get_jiter_objfile_data (reg_symbol.objfile); > - = get_jiter_objfile_data (the_objfile); It's quite annoying that separate debug info files are represented by "objfile"s... > ... > but consequently we'll have two jit breakpoints, so we also make sure we don't > set a jit breakpoint on separate debug objects like libLLVM.so.10.debug. > > Tested on x86_64-linux. Does that fix some test when running the testsuite with the fission board or something like that? I think it would be important for this to be tested. Otherwise, LGTM. Simon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler 2021-05-20 16:22 ` Simon Marchi via Gdb-patches @ 2021-05-20 22:04 ` Tom de Vries 2021-05-21 19:12 ` Tom de Vries 2021-05-21 11:27 ` Tom de Vries 1 sibling, 1 reply; 7+ messages in thread From: Tom de Vries @ 2021-05-20 22:04 UTC (permalink / raw) To: Simon Marchi, gdb-patches; +Cc: Tom Tromey On 5/20/21 6:22 PM, Simon Marchi wrote: > On 2021-05-20 11:29 a.m., Tom de Vries wrote: >> Hi, >> >> Consider a minimal test-case test.c: >> ... >> int main (void) { return 0; } >> ... >> which we can compile into llvm byte code using clang: >> ... >> $ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c >> ... >> and then run using lli, which uses the llvm jit: >> ... >> $ lli test.ll >> ... >> >> If we run this under gdb, we run into an assert: >> ... >> $ gdb -q -batch -ex run --args /usr/bin/lli test.ll >> Dwarf Error: Cannot not find DIE at 0x18a936e7 \ >> [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug] > > I guess that's unrelated, but do you know if that error is a sign of > something wrong in GDB? > I assumed not (the last binary I checked where that message occurred was a case of invalid dwarf) but ... I did a readelf -wi and after 11G I did this grep: ... $ grep 18a936e7 READELF <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram) <18aa358f> DW_AT_specification: <0x18a936e7> $ ... So this looks like a GDB problem. I also did: ... $ gdb -q -readnow /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug Reading symbols from /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug... Expanding full symbols from /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug... (gdb) ... so this could be something partial symbols related. A bit more info: ... Compilation Unit @ offset 0x18a23e52: ... <0><18a23e5d>: Abbrev Number: 1 (DW_TAG_compile_unit) <18a23e5e> DW_AT_producer : clang version 10.0.1 /home/abuild/rpmbuild/BUILD/llvm-10.0.1.src/stage1/bin/clang-10 --driver-mode=g++ -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/ExecutionEngine/Orc -I ../lib/ExecutionEngine/Orc -I /usr/include/libxml2 -I include -I ../include -fmessage-length=0 -grecord-command-line -O2 -Wall -D _FORTIFY_SOURCE=0 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -D NDEBUG -fPIC -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -O2 -g -D NDEBUG -fno-exceptions -std=c++14 -MD -MT lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -MF lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o.d -o lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -c ../lib/ExecutionEngine/Orc/LLJIT.cpp <18a23e62> DW_AT_language : 33 (C++14) <18a23e64> DW_AT_name : ../lib/ExecutionEngine/Orc/LLJIT.cpp ... <1><18a936d4>: Abbrev Number: 71 (DW_TAG_subprogram) <2><18a936d5>: Abbrev Number: 174 (DW_TAG_class_type) <18a936d7> DW_AT_calling_convention: 5 (pass by value) <18a936d8> DW_AT_byte_size : 8 <18a936d9> DW_AT_decl_file : 185 <18a936da> DW_AT_decl_line : 78 <3><18a936db>: Abbrev Number: 9 (DW_TAG_member) <18a936dc> DW_AT_name : this <18a936e0> DW_AT_type : <0x18a8bb20> <18a936e4> DW_AT_decl_file : 185 <18a936e5> DW_AT_decl_line : 78 <18a936e6> DW_AT_data_member_location: 0 <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram) <18a936e9> DW_AT_name : operator() <18a936ed> DW_AT_decl_file : 185 <18a936ee> DW_AT_decl_line : 78 <18a936ef> DW_AT_type : <0x18a557ad> <18a936f3> DW_AT_declaration : 1 <18a936f3> DW_AT_external : 1 <18a936f3> DW_AT_accessibility: 1 (public) ... <1><18aa3589>: Abbrev Number: 251 (DW_TAG_subprogram) <18aa358b> DW_AT_linkage_name: _ZZN4llvm10ThreadPool4waitEvENK3$_1clEv <18aa358f> DW_AT_specification: <0x18a936e7> <18aa3593> DW_AT_inline : 1 (inlined) <18aa3594> DW_AT_object_pointer: <0x18aa3598> ... Compilation Unit @ offset 0x18aa33d6: ... Thanks, - Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler 2021-05-20 22:04 ` Tom de Vries @ 2021-05-21 19:12 ` Tom de Vries 0 siblings, 0 replies; 7+ messages in thread From: Tom de Vries @ 2021-05-21 19:12 UTC (permalink / raw) To: Simon Marchi, gdb-patches; +Cc: Tom Tromey On 5/21/21 12:04 AM, Tom de Vries wrote: > On 5/20/21 6:22 PM, Simon Marchi wrote: >> On 2021-05-20 11:29 a.m., Tom de Vries wrote: >>> Hi, >>> >>> Consider a minimal test-case test.c: >>> ... >>> int main (void) { return 0; } >>> ... >>> which we can compile into llvm byte code using clang: >>> ... >>> $ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c >>> ... >>> and then run using lli, which uses the llvm jit: >>> ... >>> $ lli test.ll >>> ... >>> >>> If we run this under gdb, we run into an assert: >>> ... >>> $ gdb -q -batch -ex run --args /usr/bin/lli test.ll >>> Dwarf Error: Cannot not find DIE at 0x18a936e7 \ >>> [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug] >> >> I guess that's unrelated, but do you know if that error is a sign of >> something wrong in GDB? >> > > I assumed not (the last binary I checked where that message occurred was > a case of invalid dwarf) but ... > > I did a readelf -wi and after 11G I did this grep: > ... > $ grep 18a936e7 READELF > <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram) > <18aa358f> DW_AT_specification: <0x18a936e7> > $ > ... > > So this looks like a GDB problem. > > I also did: > ... > $ gdb -q -readnow > /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug > Reading symbols from > /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug... > Expanding full symbols from > /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug... > (gdb) > ... > so this could be something partial symbols related. > > A bit more info: > ... > Compilation Unit @ offset 0x18a23e52: > ... > <0><18a23e5d>: Abbrev Number: 1 (DW_TAG_compile_unit) > <18a23e5e> DW_AT_producer : clang version 10.0.1 > /home/abuild/rpmbuild/BUILD/llvm-10.0.1.src/stage1/bin/clang-10 > --driver-mode=g++ -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D > __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/ExecutionEngine/Orc > -I ../lib/ExecutionEngine/Orc -I /usr/include/libxml2 -I include -I > ../include -fmessage-length=0 -grecord-command-line -O2 -Wall -D > _FORTIFY_SOURCE=0 -fstack-protector-strong -funwind-tables > -fasynchronous-unwind-tables -fstack-clash-protection -D NDEBUG -fPIC > -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter > -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic > -Wno-long-long -Wimplicit-fallthrough -Wno-noexcept-type > -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion > -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -O2 > -g -D NDEBUG -fno-exceptions -std=c++14 -MD -MT > lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -MF > lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o.d -o > lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -c > ../lib/ExecutionEngine/Orc/LLJIT.cpp > <18a23e62> DW_AT_language : 33 (C++14) > <18a23e64> DW_AT_name : ../lib/ExecutionEngine/Orc/LLJIT.cpp > ... > <1><18a936d4>: Abbrev Number: 71 (DW_TAG_subprogram) > <2><18a936d5>: Abbrev Number: 174 (DW_TAG_class_type) > <18a936d7> DW_AT_calling_convention: 5 (pass by value) > <18a936d8> DW_AT_byte_size : 8 > <18a936d9> DW_AT_decl_file : 185 > <18a936da> DW_AT_decl_line : 78 > <3><18a936db>: Abbrev Number: 9 (DW_TAG_member) > <18a936dc> DW_AT_name : this > <18a936e0> DW_AT_type : <0x18a8bb20> > <18a936e4> DW_AT_decl_file : 185 > <18a936e5> DW_AT_decl_line : 78 > <18a936e6> DW_AT_data_member_location: 0 > <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram) > <18a936e9> DW_AT_name : operator() > <18a936ed> DW_AT_decl_file : 185 > <18a936ee> DW_AT_decl_line : 78 > <18a936ef> DW_AT_type : <0x18a557ad> > <18a936f3> DW_AT_declaration : 1 > <18a936f3> DW_AT_external : 1 > <18a936f3> DW_AT_accessibility: 1 (public) > > ... > > <1><18aa3589>: Abbrev Number: 251 (DW_TAG_subprogram) > <18aa358b> DW_AT_linkage_name: _ZZN4llvm10ThreadPool4waitEvENK3$_1clEv > <18aa358f> DW_AT_specification: <0x18a936e7> > <18aa3593> DW_AT_inline : 1 (inlined) > <18aa3594> DW_AT_object_pointer: <0x18aa3598> > ... > Compilation Unit @ offset 0x18aa33d6: > ... Filed here ( https://sourceware.org/bugzilla/show_bug.cgi?id=27898 ). Thanks, - Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler 2021-05-20 16:22 ` Simon Marchi via Gdb-patches 2021-05-20 22:04 ` Tom de Vries @ 2021-05-21 11:27 ` Tom de Vries 2021-05-21 14:07 ` Simon Marchi via Gdb-patches 2021-05-24 15:20 ` Tom Tromey 1 sibling, 2 replies; 7+ messages in thread From: Tom de Vries @ 2021-05-21 11:27 UTC (permalink / raw) To: Simon Marchi, gdb-patches [-- Attachment #1: Type: text/plain, Size: 1536 bytes --] On 5/20/21 6:22 PM, Simon Marchi wrote: > It's quite annoying that separate debug info files are represented by > "objfile"s... > Yeah, indeed. And you could even say that that's fine, but question whether they should be in the objfiles list, that is, have the default behaviour of: ... for (objfile *the_objfile : pspace->objfiles ()) { + /* Skip separate debug objects. */ + if (the_objfile->separate_debug_objfile_backlink != nullptr) + continue; ... without having to specify this, and if you need to access the separate debuginfo files, use the specific iterator for this. >> ... >> but consequently we'll have two jit breakpoints, so we also make sure we don't >> set a jit breakpoint on separate debug objects like libLLVM.so.10.debug. >> >> Tested on x86_64-linux. > > Does that fix some test when running the testsuite with the fission > board or something like that? No, though I ran into another problem :) while playing around with the jit test-cases and target boards ( https://sourceware.org/bugzilla/show_bug.cgi?id=27893 ). [ And yet another problem while looking into the missing DIE problem ( https://sourceware.org/bugzilla/show_bug.cgi?id=27894 ). > I think it would be important for this to > be tested. > I wrote this target board file, which does trigger this assert in the jit test-cases, and verified that the patch fixes all of them. During testing of the target board, I ran into another assert in gdb.python/py-objfile.exp, will file that as well. WDYT? Thanks, - Tom [-- Attachment #2: 0002-gdb-testsuite-Add-target-board-cc-with-gnu-debuglink.exp.patch --] [-- Type: text/x-patch, Size: 4289 bytes --] [gdb/testsuite] Add target board cc-with-gnu-debuglink.exp Add target board cc-with-gnu-debuglink.exp that splits off debuginfo into a seperate .debug file and links to it using .gnu_debuglink. Tested on x86_64-linux. gdb/ChangeLog: 2021-05-21 Tom de Vries <tdevries@suse.de> * contrib/cc-with-tweaks.sh: Handle -l. gdb/testsuite/ChangeLog: 2021-05-21 Tom de Vries <tdevries@suse.de> * boards/cc-with-gnu-debuglink.exp: New file. --- gdb/contrib/cc-with-tweaks.sh | 46 +++++++++++++++++++++++++- gdb/testsuite/boards/cc-with-gnu-debuglink.exp | 26 +++++++++++++++ 2 files changed, 71 insertions(+), 1 deletion(-) diff --git a/gdb/contrib/cc-with-tweaks.sh b/gdb/contrib/cc-with-tweaks.sh index 2eda76a89c2..8653dfb260e 100755 --- a/gdb/contrib/cc-with-tweaks.sh +++ b/gdb/contrib/cc-with-tweaks.sh @@ -45,6 +45,7 @@ # -i make an index (.gdb_index) # -n make a dwarf5 index (.debug_names) # -p create .dwp files (Fission), you need to also use gcc option -gsplit-dwarf +# -l creates separate debuginfo files linked to using .gnu_debuglink # If nothing is given, no changes are made myname=cc-with-tweaks.sh @@ -83,6 +84,7 @@ want_dwz=false want_multi=false want_dwp=false want_objcopy_compress=false +want_gnu_debuglink=false while [ $# -gt 0 ]; do case "$1" in @@ -92,6 +94,7 @@ while [ $# -gt 0 ]; do -n) want_index=true; index_options=-dwarf-5;; -m) want_multi=true ;; -p) want_dwp=true ;; + -l) want_gnu_debuglink=true ;; *) break ;; esac shift @@ -158,7 +161,12 @@ fi get_tmpdir () { - tmpdir=$(dirname "$output_file")/.tmp + subdir="$1" + if [ "$subdir" = "" ]; then + subdir=.tmp + fi + + tmpdir=$(dirname "$output_file")/"$subdir" mkdir -p "$tmpdir" } @@ -234,4 +242,40 @@ if [ "$want_dwp" = true ]; then fi fi +if [ "$want_gnu_debuglink" = true ]; then + # Based on gdb_gnu_strip_debug. + + # Gdb looks for the .gnu_debuglink file in the .debug subdirectory + # of the directory of the executable. + get_tmpdir .debug + + stripped_file="$tmpdir"/$(basename "$output_file").stripped + debug_file="$tmpdir"/$(basename "$output_file").debug + + # Create stripped and debug versions of output_file. + strip --strip-debug "${output_file}" \ + -o "${stripped_file}" + rc=$? + [ $rc != 0 ] && exit $rc + strip --only-keep-debug "${output_file}" \ + -o "${debug_file}" + rc=$? + [ $rc != 0 ] && exit $rc + + # The .gnu_debuglink is supposed to contain no leading directories. + link=$(basename "${debug_file}") + + ( + # Temporarily cd to tmpdir to allow objcopy to find $link + cd "$tmpdir" || exit 1 + + # Overwrite output_file with stripped version containing + # .gnu_debuglink to debug_file. + objcopy --add-gnu-debuglink="$link" "${stripped_file}" \ + "${output_file}" + rc=$? + [ $rc != 0 ] && exit $rc + ) +fi + exit $rc diff --git a/gdb/testsuite/boards/cc-with-gnu-debuglink.exp b/gdb/testsuite/boards/cc-with-gnu-debuglink.exp new file mode 100644 index 00000000000..ca977d9f165 --- /dev/null +++ b/gdb/testsuite/boards/cc-with-gnu-debuglink.exp @@ -0,0 +1,26 @@ +# Copyright 2021 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# This file is a dejagnu "board file" and is used to run the testsuite +# with contrib/cc-with-tweaks.sh -l. +# +# Example usage: +# bash$ cd $objdir +# bash$ make check-gdb \ +# RUNTESTFLAGS='--target_board=cc-with-gnu-debuglink' +# + +set CC_WITH_TWEAKS_FLAGS "-l" +load_board_description "cc-with-tweaks" ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler 2021-05-21 11:27 ` Tom de Vries @ 2021-05-21 14:07 ` Simon Marchi via Gdb-patches 2021-05-24 15:20 ` Tom Tromey 1 sibling, 0 replies; 7+ messages in thread From: Simon Marchi via Gdb-patches @ 2021-05-21 14:07 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 2021-05-21 7:27 a.m., Tom de Vries wrote: > On 5/20/21 6:22 PM, Simon Marchi wrote: >> It's quite annoying that separate debug info files are represented by >> "objfile"s... >> > > Yeah, indeed. > > And you could even say that that's fine, but question whether they > should be in the objfiles list, that is, have the default behaviour of: > ... > for (objfile *the_objfile : pspace->objfiles ()) > { > + /* Skip separate debug objects. */ > + if (the_objfile->separate_debug_objfile_backlink != nullptr) > + continue; > ... > without having to specify this, and if you need to access the separate > debuginfo files, use the specific iterator for this. I think that would be a good idea to explore. In my opinion, the fact that an objfile has separate debug info should be pretty much transparent to the rest of GDB. So I think it would make sense for these special objfiles to be hidden, unless you explicitly ask for them. >>> ... >>> but consequently we'll have two jit breakpoints, so we also make sure we don't >>> set a jit breakpoint on separate debug objects like libLLVM.so.10.debug. >>> >>> Tested on x86_64-linux. >> >> Does that fix some test when running the testsuite with the fission >> board or something like that? > > No, though I ran into another problem :) while playing around with the > jit test-cases and target boards ( > https://sourceware.org/bugzilla/show_bug.cgi?id=27893 ). Well, good news that you caught it! > [ And yet > another problem while looking into the missing DIE problem ( > https://sourceware.org/bugzilla/show_bug.cgi?id=27894 ). I do stumble on that sometimes. > >> I think it would be important for this to >> be tested. >> > > I wrote this target board file, which does trigger this assert in the > jit test-cases, and verified that the patch fixes all of them. I thought that fission meant "separate debug info", but I think I was wrong... I always confuse fission and separate debug info. We don't already have a board file that generates separate debug info, in that sense: https://sourceware.org/gdb/current/onlinedocs/gdb/Separate-Debug-Files.html ? Looks like we don't, so it would be useful to add one. Since there are two ways of specifying separate debug info (by debuglink and by build-id, I think it would be nice to have a board for each. But just adding the debuglink one would already be an improvement. And once the separate debug info file is found, I guess the code paths don't differ much based on through which method the file was found. > During testing of the target board, I ran into another assert in > gdb.python/py-objfile.exp, will file that as well. WDYT? I think that board file should be added. Simon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler 2021-05-21 11:27 ` Tom de Vries 2021-05-21 14:07 ` Simon Marchi via Gdb-patches @ 2021-05-24 15:20 ` Tom Tromey 1 sibling, 0 replies; 7+ messages in thread From: Tom Tromey @ 2021-05-24 15:20 UTC (permalink / raw) To: Tom de Vries; +Cc: gdb-patches >>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes: Simon> It's quite annoying that separate debug info files are represented by Simon> "objfile"s... Tom> Yeah, indeed. Tom> And you could even say that that's fine, but question whether they Tom> should be in the objfiles list, that is, have the default behaviour of: I've long thought this was a design error, and that having the separate debug objfile be replaced with supplementary BFDs attached to the main objfile would be a better design. If someone wants to implement this, I'm all for it. Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-05-24 15:20 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-20 15:29 [PATCH][gdb/breakpoint] Fix assert in jit_event_handler Tom de Vries 2021-05-20 16:22 ` Simon Marchi via Gdb-patches 2021-05-20 22:04 ` Tom de Vries 2021-05-21 19:12 ` Tom de Vries 2021-05-21 11:27 ` Tom de Vries 2021-05-21 14:07 ` Simon Marchi via Gdb-patches 2021-05-24 15:20 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox