From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7032 invoked by alias); 28 Oct 2009 19:35:01 -0000 Received: (qmail 7016 invoked by uid 22791); 28 Oct 2009 19:35:01 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Oct 2009 19:34:56 +0000 Received: (qmail 7795 invoked from network); 28 Oct 2009 19:34:54 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Oct 2009 19:34:54 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: --gc-section leftovers workaround. Date: Wed, 28 Oct 2009 19:35:00 -0000 User-Agent: KMail/1.9.10 Cc: Paul Pluzhnikov References: <200910281851.01364.pedro@codesourcery.com> <8ac60eac0910281223q144eb548qe92cc9758d184a96@mail.gmail.com> In-Reply-To: <8ac60eac0910281223q144eb548qe92cc9758d184a96@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910281935.26781.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00676.txt.bz2 On Wednesday 28 October 2009 19:23:11, Paul Pluzhnikov wrote: > On Wed, Oct 28, 2009 at 11:51 AM, Pedro Alves wrote: > > > With --gc-sections, gnu ld zeros out the start addresses of > > unreferences FDEs, but leaves them behind. > > I believe the same thing happens when there are multiple instances of the > same inline function in several translation units: one is selected, and > debug info for the other ones gets zero start address. Ah. > The patch looks good to me. It wasn't unfortunately. :-( I had posted an early patch that got one thing wrong. It compared FDE->initial_location to (FDE+1)->initial_location, to check for overlap, and discarded FDE if so. But, this isn't correct since FDE may be the valid one we should keep, and (FDE+1)->initial_location could be 0! The corrected patch first looks for the first FDE with initial_location != 0 and uses that one for overlap and discarding decisions. Anyway, I think that patch is itself clearer than I can manage to explain it. :-) -- Pedro Alves