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