Malformed DWARF from llc?

[llvmbot]

Bugzilla Link	9995
Resolution	FIXED
Resolved on	Jan 15, 2013 00:45
Version	2.9
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

It looks like llc might be producing malformed DWARF debug info. I'm no DWARF expert, so I'm having trouble diagnosing it. Here's an example: compile this to LLVM IR with "clang -c -g -emit-llvm":

void bar();
void foo() { bar(); }

Then generate an object file via "llc" and "as". Running "dumpbin" on the resulting object file (linux elf-64) gives errors like:

AT of 16359 (0x3fe7) is unknown to dwarfdump. Continuing.
...
dwarfdump ERROR: dwarf_srclines: DW_DLE_ATTR_FORM_BAD (114)

There aren't any issues if the object file is generated directly by clang. But I need to preserve debug info from LLVM IR through llc (scenario: use clang to compile library code with debug info, generate additional IR and link it with library IR, then finish codegen with llc and as). Thanks in advance for any suggestions.

[llvmbot]

Could you post the contents of the __debug_abbrev section from the .s file that gets generated? I'm not seeing this bug but I'm running on a very different system (clang-trunk, MacOSX).

The unknown attribute 0x3fe7 is DW_AT_APPLE_omit_frame_ptr, which dwarfdump should be able to skip over safely, so I wonder if the FORM_BAD error from dwarf_srclines() is caused by some other problem.

[llvmbot]

Clang-generated LLVM IR
clang -c -g -emit-llvm -o test.bc test.c
llvm-dis test.bc

[llvmbot]

llc-generated assembly
llc -o test.s test.bc

[llvmbot]

Thanks for looking. I've attached the LLVM IR and assembly for the two-line example described previously. Here's the debug_abbrev section:

.section	.debug_abbrev,"",@progbits

.Labbrev_begin:
.byte 1 # Abbreviation Code
.byte 17 # DW_TAG_compile_unit
.byte 1 # DW_CHILDREN_yes
.byte 37 # DW_AT_producer
.byte 8 # DW_FORM_string
.byte 19 # DW_AT_language
.byte 5 # DW_FORM_data2
.byte 3 # DW_AT_name
.byte 8 # DW_FORM_string
.byte 82 # DW_AT_entry_pc
.byte 1 # DW_FORM_addr
.byte 16 # DW_AT_stmt_list
.byte 1 # DW_FORM_addr
.byte 27 # DW_AT_comp_dir
.byte 8 # DW_FORM_string
.byte 0 # EOM(1)
.byte 0 # EOM(2)
.byte 2 # Abbreviation Code
.byte 46 # DW_TAG_subprogram
.byte 0 # DW_CHILDREN_no
.byte 3 # DW_AT_name
.byte 8 # DW_FORM_string
.byte 58 # DW_AT_decl_file
.byte 11 # DW_FORM_data1
.byte 59 # DW_AT_decl_line
.byte 11 # DW_FORM_data1
.byte 63 # DW_AT_external
.byte 12 # DW_FORM_flag
.byte 17 # DW_AT_low_pc
.byte 1 # DW_FORM_addr
.byte 18 # DW_AT_high_pc
.byte 1 # DW_FORM_addr
.byte 64 # DW_AT_frame_base
.byte 10 # DW_FORM_block1
.ascii "\347\177" # DW_AT_APPLE_omit_frame_ptr
.byte 12 # DW_FORM_flag
.byte 0 # EOM(1)
.byte 0 # EOM(2)
.byte 0 # EOM(3)
.Labbrev_end:

[llvmbot]

Mark is correct. DW_AT_stmt_list is generating a FORM
of DW_FORM_addr, but the form generated should be a reference
form to reference the .debug_line section's line data.

The DWARF2 spec wrote about DW_FORM_addr inconsistently
and confusedly (we got it wrong in 1993).
For the real meaning check the DWARF3 or DWARF4 specs.

I'm the author and maintainer of dwarfdump and libdwarf
and a member of the DWARF committee, BTW. Doesn't
make me right all the time of course :-)

[llvmbot]

Wim is correct that dwarfdump should be able to skip attributes
it knows nothing about.

I heard ( 2 January 2012)
about the DW_FORM_addr bug from a dwarfdump
user who generated the bad DWARF2 on Ubuntu 11.10 x86_64
with clang++ -O0 -g const.cpp and reported the libdwarf
error to me.

The clang bug is awkward for libdwarf because it violates
a basic DWARF definition of FORMs.
Introducing a workaround in libdwarf
feels wrong...

[llvmbot]

Current head clang emits AT_stmt_list using FORM_data4. Is that a problem? I realize that it isn't what DWARF3/4 spec, but we still claim to emit DWARF2 for now.

Should this bug still be open?

[llvmbot]

If it's emitting FORM_data4 for the attr
and saying it is DWARF2
then all is well. It's the right FORM
for DWARF2 and this sort of attribute DWARF2.
Which means there is no bug left. Fixed.
(I did not try llc, I just am commenting on
Nick L's question, saying the answer to his
question is no, there is no reason to keep it open)

[lattner]

This is apparently fixed.