This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
GAS not emitting debug_line section when it should
- To: binutils at sources dot redhat dot com
- Subject: GAS not emitting debug_line section when it should
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: 16 Jun 2001 00:18:27 -0400
- Cc: rth at redhat dot com
If we only have .file directives, we never output .debug_line section.
This is wrong, since the dwarf2 info may have DW_AT_decl_file
attributes in it, referring to the file numbers, and if you don't emit
at least the headers of the .debug_line section, we have no way to
map these file numbers to file names.
This is GAS's dwarf2 line info generator's fault.
Check this out:
compile safe-ctype.c from libiberty with dwarf2 info on.
There is no real code, just tables. So we have no .loc's at all in
there.
.file "safe-ctype.i"
.file 1 "safe-ctype.i"
.section .debug_abbrev
.Ldebug_abbrev0:
.section .text
.Ltext0:
.section .debug_info
.Ldebug_info0:
.section .debug_line
.Ldebug_line0:
.file 2 "../include/safe-ctype.h"
.file 3 "/usr/include/bits/types.h"
.file 4 "/usr/include/bits/sched.h"
.file 5 "/usr/include/bits/pthreadtypes.h"
.file 6 "/usr/include/wchar.h"
.file 7 "/usr/include/_G_config.h"
.file 8 "/usr/include/gconv.h"
.file 9 "/usr/include/libio.h"
.file 10 "/usr/lib/gcc-lib/powerpc-linux/3.0/include/stdio.h"
<...>
.file 11 "safe-ctype.c"
.file 12 "/usr/lib/gcc-lib/powerpc-linux/3.0/include/stddef.h"
.file 13 "/usr/lib/gcc-lib/powerpc-linux/3.0/include/stdarg.h"
<other data, the debug_info sections, etc, but not a single .loc>
Yet, even though we have file names, we produce no debug_line section.
This is completely wrong.
If we have DW_AT_decl_file attributes, with numbers, you must have a
way to get the filenames for these numbers. Unless the value of the
attribute is 0.
The easiest thing to do here is to just be emitting a debug line
section with only the header info and whatnot (which is where the
filenames normally go), and a zero length statement program.
Either that, or a statement program consisting of DW_LNE_define_file
opcodes with the right parameters.
Right now what we do is totally bogus and wrong. We both leave file
numbers in the DW_AT_decl_file attributes, and provide no way to get
the filename for them.
The easiest way to see and example of this is to compile safe-ctype.c
from libiberty with -gdwarf-2 on, and have a gas that supports .file
and .loc directives (I forget what version these things were
introduced in).
--Dan
P.S. I'm not on the binutils list, so please keep me in the CC
--
"I busted a mirror and got seven years bad luck, but my lawyer
thinks he can get me five.
"-Steven Wright