Aliaksei Zasenka via llvm-dev
2017-Apr-04 15:25 UTC
[llvm-dev] GDB doesn't work with IR-originated debug info
Hi all, Need your help. I added some debug information to my code according to Kaleidoscope-9 sample and got stuck with a GDB error: (gdb) info functions> invalid dwarf2 offset 1849950870 >My module is a DLL built with llc+ld toolchain. Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] "void") DW_AT_encoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) DW_AT_high_pc [DW_FORM_data4] (0x000002b4) DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] "FB_FPUMP at HORIZONTAL") DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*) DW_ AT_external [DW_FORM_flag_present] (true) In the original object file the corresponding record was: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] "void") DW_AT_encoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x00000000000037e0) DW_AT_high_pc [DW_FORM_data4] (0x000002b4) DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] "FB_FPUMP at HORIZONTAL") DW_AT_type [DW_FORM_ref_addr] (*0x0000000000000296*) DW_AT_external [DW_FORM_flag_present] (true) There are lots of subprogram records like this. Any ideas what may be done to fix that? My debugger config: GNU gdb (GDB) 7.10.1 This GDB was configured as "i686-w64-mingw32". OS : Win7 64-bit -- Best regards, Alexey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170404/b8ff0140/attachment.html>
Jameson Nash via llvm-dev
2017-Apr-11 20:39 UTC
[llvm-dev] GDB doesn't work with IR-originated debug info
What version of LLVM are you using? This looks similar to a bug that I fixed in 4.0 (R290809). I mostly only tested for `-dwarf-version 4`, so you may get better results with using the newer format as well. But if it's broken on the latest version of LLVM, can you post a gist/pastebin of the LL file (e.g. `clang -S -emit-llvm`)? That'll help with reproducing it and seeing which entry is still getting relocated incorrectly in dwarf version 2. On Tue, Apr 4, 2017 at 11:25 AM Aliaksei Zasenka via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > Need your help. > > I added some debug information to my code according to Kaleidoscope-9 > sample and got stuck with a GDB error: > > (gdb) info functions > invalid dwarf2 offset 1849950870 > > > My module is a DLL built with llc+ld toolchain. Target triple: > 'i686-w64-mingw32'. > Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the > dll gave the following: > > 0x00000296: DW_TAG_base_type [10] > DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] > "void") > DW_AT_encoding [DW_FORM_data1] (0x00) > DW_AT_byte_size [DW_FORM_data1] (0x00) > .... > 0x00000cf8: DW_TAG_subprogram [16] * > DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) > DW_AT_high_pc [DW_FORM_data4] (0x000002b4) > DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] > "FB_FPUMP at HORIZONTAL") > DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*) > DW_ > AT_external [DW_FORM_flag_present] (true) > > > In the original object file the corresponding record was: > > 0x00000296: DW_TAG_base_type [10] > DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] > "void") > DW_AT_encoding [DW_FORM_data1] (0x00) > DW_AT_byte_size [DW_FORM_data1] (0x00) > .... > > 0x00000cf8: DW_TAG_subprogram [16] * > DW_AT_low_pc [DW_FORM_addr] (0x00000000000037e0) > DW_AT_high_pc [DW_FORM_data4] (0x000002b4) > DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] > "FB_FPUMP at HORIZONTAL") > DW_AT_type [DW_FORM_ref_addr] (*0x0000000000000296*) > DW_AT_external [DW_FORM_flag_present] (true) > > > There are lots of subprogram records like this. > > Any ideas what may be done to fix that? > > My debugger config: > GNU gdb (GDB) 7.10.1 > This GDB was configured as "i686-w64-mingw32". > OS : Win7 64-bit > > -- > Best regards, > Alexey Zasenko > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170411/a2ab3329/attachment.html>
Aliaksei Zasenka via llvm-dev
2017-Apr-29 09:45 UTC
[llvm-dev] GDB doesn't work with IR-originated debug info
Hi Jameson, excuse my being silent so long. I've checked again and everything is OK in 4.0 and in the latest trunk. My working version is 3.9 but I was sure that I had checked with 4.0 as well. Btw, I found a workaround for 3.9. If -generate-type-units is set to llc the correct relocations are generated. Thanks for your support. 2017-04-11 23:39 GMT+03:00 Jameson Nash <vtjnash at gmail.com>:> What version of LLVM are you using? This looks similar to a bug that I > fixed in 4.0 (R290809). I mostly only tested for `-dwarf-version 4`, so you > may get better results with using the newer format as well. But if it's > broken on the latest version of LLVM, can you post a gist/pastebin of the > LL file (e.g. `clang -S -emit-llvm`)? That'll help with reproducing it and > seeing which entry is still getting relocated incorrectly in dwarf version > 2. > > > On Tue, Apr 4, 2017 at 11:25 AM Aliaksei Zasenka via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Need your help. >> >> I added some debug information to my code according to Kaleidoscope-9 >> sample and got stuck with a GDB error: >> >> (gdb) info functions >> invalid dwarf2 offset 1849950870 >> >> >> My module is a DLL built with llc+ld toolchain. Target triple: >> 'i686-w64-mingw32'. >> Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the >> dll gave the following: >> >> 0x00000296: DW_TAG_base_type [10] >> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] >> "void") >> DW_AT_encoding [DW_FORM_data1] (0x00) >> DW_AT_byte_size [DW_FORM_data1] (0x00) >> .... >> 0x00000cf8: DW_TAG_subprogram [16] * >> DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) >> DW_AT_high_pc [DW_FORM_data4] (0x000002b4) >> DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) >> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] >> "FB_FPUMP at HORIZONTAL") >> DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*) >> DW_ >> AT_external [DW_FORM_flag_present] (true) >> >> >> In the original object file the corresponding record was: >> >> 0x00000296: DW_TAG_base_type [10] >> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] >> "void") >> DW_AT_encoding [DW_FORM_data1] (0x00) >> DW_AT_byte_size [DW_FORM_data1] (0x00) >> .... >> >> 0x00000cf8: DW_TAG_subprogram [16] * >> DW_AT_low_pc [DW_FORM_addr] (0x00000000000037e0) >> DW_AT_high_pc [DW_FORM_data4] (0x000002b4) >> DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) >> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] >> "FB_FPUMP at HORIZONTAL") >> DW_AT_type [DW_FORM_ref_addr] (*0x0000000000000296*) >> DW_AT_external [DW_FORM_flag_present] (true) >> >> >> There are lots of subprogram records like this. >> >> Any ideas what may be done to fix that? >> >> My debugger config: >> GNU gdb (GDB) 7.10.1 >> This GDB was configured as "i686-w64-mingw32". >> OS : Win7 64-bit >> >> -- >> Best regards, >> Alexey Zasenko >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170429/1c0741a9/attachment.html>
Maybe Matching Threads
- [LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
- [LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
- [LLVMdev] How is variable info retrieved in debugging for executables generated by llvm backend?
- distinct DISubprograms hindering sharing inlined subprogram descriptions
- Hardware ASan Generating Unknown Instruction