Some dwarf "nitpicks"
Roland McGrath
roland at redhat.com
Wed Mar 9 17:51:04 UTC 2011
> > This produces a zero-length .debug_line section but a CU with a
> > DW_AT_stmt_list attribute pointing to its start. That is invalid
> > DWARF and hence a GCC bug. The place where DW_AT_stmt_list points
> > must have a valid line information header, even if that says it's an
> > empty table. I think what would be most correct here is to omit the
> > DW_AT_stmt_list attribute entirely from that CU DIE.
>
> Actually, the header is there, but there are no tables.
That's not what I saw.
$ gcc -g -S -xc <(echo 'static int x;') -o - | grep debug_line
.section .debug_line,"", at progbits
.Ldebug_line0:
.long .Ldebug_line0
The only entrance into the section is that one:
.section .debug_line,"", at progbits
.Ldebug_line0:
.text
So the section is indeed empty.
> But since the debug_line table header is actually there, dwarflint is
> still not really happy. empty.o as produced by my patched gcc attached.
>
> $ eu-dwarflint empty.o
> warning: .debug_line: table 0: the file #1 `empty.c' is not used.
> error: .debug_line: table 0: sequence of opcodes not terminated with
> DW_LNE_end_sequence.
>
> So maybe a better solution would be to just add a dummy end_sequence.
I'm not sure the specification is clear this is invalid. It says, "Every
line number program sequence must end with a DW_LNE_end_sequence
instruction..." But I don't see any wording that says there actually has
to be any line number program sequence at all. Note that a .debug_line
table with no line number program sequences still has a valid meaning: it
defines the include directory path for the CU, and it defines the file
entries that the CU's DW_AT_decl_file et al refer to.
Thanks,
Roland
More information about the elfutils-devel
mailing list