* Re: Debuggin info for unused sections [not found] <DB7B9DAED0B660469F69536325A1D65A042E0781@penmb01.corp.atmel.com> @ 2012-01-06 10:27 ` nick clifton 2012-01-06 11:39 ` Andrew Burgess 2012-01-06 14:11 ` Tom Tromey 0 siblings, 2 replies; 5+ messages in thread From: nick clifton @ 2012-01-06 10:27 UTC (permalink / raw) To: Kaushik, Praveen_Kumar, gdb; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Debuggin info for unused sections 2012-01-06 10:27 ` Debuggin info for unused sections nick clifton @ 2012-01-06 11:39 ` Andrew Burgess 2012-01-06 14:11 ` Tom Tromey 1 sibling, 0 replies; 5+ messages in thread From: Andrew Burgess @ 2012-01-06 11:39 UTC (permalink / raw) To: binutils; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Debuggin info for unused sections 2012-01-06 10:27 ` Debuggin info for unused sections nick clifton 2012-01-06 11:39 ` Andrew Burgess @ 2012-01-06 14:11 ` Tom Tromey 2012-01-06 16:01 ` nick clifton 1 sibling, 1 reply; 5+ messages in thread From: Tom Tromey @ 2012-01-06 14:11 UTC (permalink / raw) To: nick clifton; +Cc: Kaushik, Praveen_Kumar, gdb, binutils >>>>> "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Debuggin info for unused sections 2012-01-06 14:11 ` Tom Tromey @ 2012-01-06 16:01 ` nick clifton 2012-01-06 23:11 ` Cary Coutant 0 siblings, 1 reply; 5+ messages in thread From: nick clifton @ 2012-01-06 16:01 UTC (permalink / raw) To: Tom Tromey; +Cc: Kaushik, Praveen_Kumar, gdb, binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Debuggin info for unused sections 2012-01-06 16:01 ` nick clifton @ 2012-01-06 23:11 ` Cary Coutant 0 siblings, 0 replies; 5+ messages in thread From: Cary Coutant @ 2012-01-06 23:11 UTC (permalink / raw) To: nick clifton; +Cc: Tom Tromey, Kaushik, Praveen_Kumar, gdb, binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-06 23:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <DB7B9DAED0B660469F69536325A1D65A042E0781@penmb01.corp.atmel.com> 2012-01-06 10:27 ` Debuggin info for unused sections nick clifton 2012-01-06 11:39 ` Andrew Burgess 2012-01-06 14:11 ` Tom Tromey 2012-01-06 16:01 ` nick clifton 2012-01-06 23:11 ` Cary Coutant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).