[llvm-dev] GDB doesn't work with IR-originated debug info

[Aliaksei Zasenka via llvm-dev]

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>