Re: Debuggin info for unused sections

Re: Debuggin info for unused sections

[nick clifton]

Hi Praveen,

   [I have added the GDB list as I now think that this issue affects them.]

> 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.

Cheers
   Nick

Re: Debuggin info for unused sections

[Andrew Burgess]

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

Re: Debuggin info for unused sections

[Tom Tromey]

>>>>> "nick" == nick clifton <nickc@redhat.com> writes:

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

Could you file this in gdb bugzilla?

Tom

Re: Debuggin info for unused sections

[nick clifton]

Hi Tom,

> Could you file this in gdb bugzilla?

Done:

http://sourceware.org/bugzilla/show_bug.cgi?id=13568

I should file a binutils bug report too.  I'll follow up on that shortly.

Cheers
   Nick

Re: Debuggin info for unused sections

[Cary Coutant]

This isn't just a problem with garbage collection -- we've run into
similar issues with COMDAT handling. I've been wanting to fix gcc for
a long time to emit the debug info for a function into the same COMDAT
group as the function itself, so that we can eliminate the duplicate
debug info along with the duplicate code. At least with COMDAT groups,
the linker is able to do something a bit more reasonable (but at some
cost) -- we remap the discarded sections' relocations to the
corresponding kept sections. Thus, the debug info that's left actually
has valid, if redundant, addresses in it.

With garbage collection, we've limped along using a value of zero for
symbols in discarded sections. In GNU ld, where the linker applies a 0
for any such relocation, this can cause the false end-of-list problem
in .debug_ranges that Andrew noted. (We don't have that particular
problem when using gold, because gold still applies the addend, and we
get a range list entry of 0..0+function_size, which doesn't terminate
the list.) I'm a bit surprised at the gdb crash reported here, since
my understanding was that it has been taught to ignore debug info for
functions and line ranges that appear to start at 0.

As far as I know, then, things ought to still work, even though it's
not an ideal situation. Of course, for targets where a function might
reasonably be placed at address 0, the existing hacks don't work.

To improve things, I think we need to do the things that Nick
outlined: when using -ffunction-sections, gcc and gas should emit the
various debug contributions for each function in separate sections.
While we're doing that, we should also attach the debug sections to a
function's group when the function is in a COMDAT group.

When doing garbage collection, the linker needs to be able to figure
out which sections can be discarded. Normally, it follows references
to build a transitive closure, but for debug info, the references are
reversed: there are no relocations from the code to the debug info,
but there are relocations from the debug info to the code. The linker
will have to be taught to understand the reversed direction of these
references. (That same reasoning applies to static constructors as
well; I think we should be able to discard constructors that only
reference otherwise-unreachable sections.)

Even better, to my mind, we could use (both COMDAT and non-COMDAT)
group sections to tie the code and debug info (and static data, and
eh_frame info, etc.) together into a single group. Garbage collection
could then treat each such group as an atomic unit: any reference to a
group member section makes the whole group reachable. Back when we
added COMDAT group sections to the ELF format, we had in mind
something like this, which is why each group section begins with a
flag word with GRP_COMDAT set to identify a COMDAT group.

I'm *not* in favor of having the linker remove bits and pieces of the
various debug sections -- it's just too expensive and introduces yet
another place where we depend on some external format.

-cary