From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22098 invoked by alias); 6 Jan 2012 11:39:26 -0000 Received: (qmail 22072 invoked by uid 22791); 6 Jan 2012 11:39:25 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mms3.broadcom.com (HELO MMS3.broadcom.com) (216.31.210.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 11:39:12 +0000 Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 06 Jan 2012 03:46:51 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB02.corp.ad.broadcom.com (10.9.200.133) with Microsoft SMTP Server id 8.2.247.2; Fri, 6 Jan 2012 03:38:26 -0800 Received: from [10.177.72.88] (unknown [10.177.72.88]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id B26EABC398; Fri, 6 Jan 2012 03:38:56 -0800 (PST) Message-ID: <4F06DD4F.5080006@broadcom.com> Date: Fri, 06 Jan 2012 11:39:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "binutils@sourceware.org" cc: "gdb@sourceware.org" Subject: Re: Debuggin info for unused sections References: <4F06CC32.10102@redhat.com> In-Reply-To: <4F06CC32.10102@redhat.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00016.txt.bz2 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