This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Debuggin info for unused sections


On 06/01/2012 10:25, nick clifton wrote:

While using -gc-sections to remove unused sections, the section is removed but the debug info in not removed.

In,

a.c:
int main()
{
    return 0;
}
int fun ()
{
    return 0;
}

gcc -g3 -ffunction-sections -Wl,-gc-sections a.c
readelf -wl a.out
gives

Line Number Statements:
    Extended opcode 2: set Address to 0x4003f6
    Special opcode 6: advance Address by 0 to 0x4003f6 and Line by 1 to 2
    Special opcode 62: advance Address by 4 to 0x4003fa and Line by 1 to 3
    Special opcode 76: advance Address by 5 to 0x4003ff and Line by 1 to 4
    Advance PC by 2 to 0x400401
    Extended opcode 1: End of Sequence

    Extended opcode 2: set Address to 0x0
    Special opcode 11: advance Address by 0 to 0x0 and Line by 6 to 7
    Special opcode 62: advance Address by 4 to 0x4 and Line by 1 to 8
    Special opcode 76: advance Address by 5 to 0x9 and Line by 1 to 9
    Advance PC by 2 to 0xb
    Extended opcode 1: End of Sequence


Originally I had just thought that this was a missed opportunity for the
linker to remove unneeded debug information.  But then it occurred to me
that leaving the bogus line number information in could cause problems
for GDB.  As in:

    % gdb -nw a.out
    GNU gdb (GDB) 7.4.50.20120106-cvs
    [...]
    (gdb) break a.c:6
    Bus error (core dumped)

So it seems that we really do need to remove it after all.  I will look
into it when I have the time.

Indeed, it's not just in the line table where this causes problems, when sections are garbage collected all the DWARF ends up with bogus entries and all of these can confuse gdb, though some are more serious than others.


I asked about this issue recently,

http://sourceware.org/ml/binutils/2011-11/msg00223.html

In the case I was hitting garbage collection was causing end-of-list markers to appear in the debug_ranges data with the result that gdb couldn't figure out the correct owner of some areas of code.

To work around my immediate problem I added code to the bfd discard_info hook and just rewrote the debug_ranges section to remove unneeded references, but the structure of debug_ranges is pretty regular so that was easy :)

Nick has previously suggested splitting the debug info into separate sections in the assembler/compiler then having the linker garbage collect them, I think this would be by far the cleanest/simplest solution.

Cheers,

Andrew







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]