Generate .debug_info for asm files?

Dear LLVM devs,

I’ve noticed that LLVM’s assembler (and hence clang) doesn’t generate debug data when assembling, even when run with “-g”.

Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don’t have a DIE in the .debug_info section which identifies the compilation unit. (I’m not an expert on GDB, but this is the conclusion I have drawn from single-stepping through GDB on some test binaries.)

Would you be interested in a patch which makes the assembler generate .debug_info?

Thanks,
Alex Dowad

Sorry, let me correct that: the assembler does generate the .debug_info
section (as well as line number data) when run with "-g". I was wrong,
sorry.

The issue I am having with GDB is occurring because using ".file"
directives with LLVM's assembler doesn't automatically add
DW_TAG_compile_unit DIEs to the .debug_info and .debug_aranges sections.
(It does with GAS.)

When the assembler is run with -g, it does generate the DW_TAG_compile_unit
DIEs. There is no problem there. The problem comes when you want to
manually include your own debug data using assembler directives. This is
useful when the assembler is generated from some other source.

So what I should have said is: would you be interested in a patch which
makes ".file" directives generate DW_TAG_compile_unit DIEs?

Thanks, Alex Dowad

Dear LLVM devs,

I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g”.

What are you seeing exactly? because my clang using the integrated as on Darwin definitely produces debug info for assembly input:

$ cat test.s

.globl func
func:
  ret

$ clang -g test.s -c

$ llvm-dwarfdump test.o
test.o: file format Mach-O 64-bit x86-64
[…]

.debug_info contents:
0x00000000: Compile Unit: length = 0x0000008e version = 0x0002 abbr_offset = 0x0000 addr_size = 0x08 (next CU at 0x00000092)

0x0000000b: DW_TAG_compile_unit [1] *
0x0000000c: DW_AT_stmt_list [DW_FORM_data4] (0x00000000)
0x00000010: DW_AT_low_pc [DW_FORM_addr] (0x0000000000000000)
0x00000018: DW_AT_high_pc [DW_FORM_addr] (0x0000000000000001)
0x00000020: DW_AT_name [DW_FORM_string] ("test.s")
0x00000027: DW_AT_comp_dir [DW_FORM_string] ("/Users/fred/tmp")
0x00000037: DW_AT_producer [DW_FORM_string] ("Apple LLVM version 6.0 (clang-600.0.39) (based on LLVM 3.5svn)")
0x00000076: DW_AT_language [DW_FORM_data2] (0x8001)

0x00000078: DW_TAG_label [2] *
0x00000079: DW_AT_name [DW_FORM_string] ("func")
0x0000007e: DW_AT_decl_file [DW_FORM_data4] (0x00000001)
0x00000082: DW_AT_decl_line [DW_FORM_data4] (0x00000006)
0x00000086: DW_AT_low_pc [DW_FORM_addr] (0x0000000000000000)
0x0000008e: DW_AT_prototyped [DW_FORM_flag] (0x00)

0x0000008f: DW_TAG_unspecified_parameters [3]

0x00000090: NULL

0x00000091: NULL

[…]

.debug_lines contents:
[…]
Address Line Column File ISA Flags
------------------ ------ ------ ------ --- -------------
0x0000000000000000 4 0 1 0 is_stmt
0x0000000000000001 4 0 1 0 is_stmt end_sequence

Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but this is the conclusion I have drawn from single-stepping through GDB on some test binaries.)

I’m not sure how that interacts with user supplied debug annotations though.

Fred

Sure, a patch to be compatible here sounds great. Thanks!

Of course!

Thanks.