GDB doesn't work with IR-originated debug info

Project Infrastructure LLVM Dev List Archives
1

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@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@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

2

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.

3

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.