Re: Debuggin info for unused sections

["Andrew Burgess" <aburgess@broadcom.com>]

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