Re: Some dwarf "nitpicks"

[Roland McGrath <roland at redhat dot com>]

> > 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,"",@progbits
	.Ldebug_line0:
		.long	.Ldebug_line0

The only entrance into the section is that one:

	.section	.debug_line,"",@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