From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13967 invoked by alias); 6 Jan 2012 23:11:22 -0000 Received: (qmail 13946 invoked by uid 22791); 6 Jan 2012 23:11:20 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-yx0-f169.google.com (HELO mail-yx0-f169.google.com) (209.85.213.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 23:11:05 +0000 Received: by yenm2 with SMTP id m2so337912yen.0 for ; Fri, 06 Jan 2012 15:11:04 -0800 (PST) Received: by 10.236.175.199 with SMTP id z47mr10497751yhl.93.1325891464352; Fri, 06 Jan 2012 15:11:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.175.199 with SMTP id z47mr10497728yhl.93.1325891464164; Fri, 06 Jan 2012 15:11:04 -0800 (PST) Received: by 10.100.234.30 with HTTP; Fri, 6 Jan 2012 15:11:04 -0800 (PST) In-Reply-To: <4F071A79.8080301@redhat.com> References: <4F06CC32.10102@redhat.com> <4F071A79.8080301@redhat.com> Date: Fri, 06 Jan 2012 23:11:00 -0000 Message-ID: Subject: Re: Debuggin info for unused sections From: Cary Coutant To: nick clifton Cc: Tom Tromey , "Kaushik, Praveen_Kumar" , gdb@sourceware.org, binutils@sourceware.org X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00025.txt.bz2 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