Re: Some dwarf "nitpicks"

[Mark Wielaard <mjw at redhat dot com>]

Hi Roland,

> > That of course is an invalid .debug_info section, but there really
> > is no
> > reason for gas to output the .debug_line section since there was no
> > explicit .debug_line sections, nor where there any .loc or .line
> > directives.
> 
> You mean any .loc or two-operand .file directives.

Yes, typo. Although I admit I hadn't noticed .file with one argument
had different semantics.

> > But if this gas bug is fixed we might
> > need to fix gcc to not unconditionally produce a
> > DW_AT_line_stmt_list for the CU.
> 
> Yes, it could emit DW_AT_stmt_list only if it ever emitted a
> two-operand .file directive. I think the only situation in
> which it would ever fail to emit one of those is a file that
> does not define anything at all
> (i.e. empty or containing only type and extern declarations).
> That is sufficiently rare and meaningless that it doesn't
> seem really worth giving gcc a special case for it.

I assume it is rare, but indeed, a simple file with just
#include <stdio.h> seems a testcase.

> If anything, I'd almost consider it a feature
> if gcc *did* emit .file 1 "empty.c" for an empty file
> --then you get DWARF data that lists each and every source
> file that was compiled, so that things like the rpmbuild
> procedure that copies sources into /usr/src/debug
> would include some file of #include's and macros and
> whatnot that led to defining nothing.

Doesn't/Shouldn't it also look at the CUs name and comp_dir?
BTW. Where is the code that does the splitting/copying hosted?

Thanks,

Mark