From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24536 invoked by alias); 19 Jun 2006 08:16:34 -0000 Received: (qmail 24526 invoked by uid 22791); 19 Jun 2006 08:16:34 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 08:16:31 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-04.spheriq.net with ESMTP id k5J8GRWI014457 for ; Mon, 19 Jun 2006 08:16:27 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id k5J8GQZa026864 for ; Mon, 19 Jun 2006 08:16:27 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id k5J8GKhi025354 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 19 Jun 2006 08:16:24 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 887C4DA48; Mon, 19 Jun 2006 08:15:58 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BEA8347373; Mon, 19 Jun 2006 08:15:56 +0000 (GMT) Received: from crx549.cro.st.com (crx549.cro.st.com [164.129.44.49]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CHS47136 (AUTH "frederic riss"); Mon, 19 Jun 2006 10:15:54 +0200 (CEST) Subject: Re: Problems with startup code symbols (Copious warnings) From: Frederic RISS To: Jim Blandy Cc: Steven Johnson , gdb@sources.redhat.com In-Reply-To: References: <4487C21F.2090907@sakuraindustries.com> <44881434.2040207@sakuraindustries.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 09:36:00 -0000 Message-Id: <1150704956.2480.65.camel@crx549.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00123.txt.bz2 On Wed, 2006-06-14 at 17:12 -0700, Jim Blandy wrote: [...] > /* When using the GNU linker, .gnu.linkonce. sections are used to > eliminate duplicate copies of functions and vtables and such. > The linker will arbitrarily choose one and discard the others. > The AT_*_pc values for such functions refer to local labels in > these sections. If the section from that file was discarded, the > labels are not in the output, so the relocs get a value of 0. > If this is a discarded function, mark the pc bounds as invalid, > so that GDB will ignore it. */ > if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0) > return 0; > > (Linkonce sections are a crock: if a section of code is discarded, the > debug info should be discarded along with it, but there's no way to do > that with linkonce sections.) But in your case, you really have a > compilation unit at address zero. [...] > If anyone can see a way to handle discarded linkonce sections better, > I'd love to hear it. What about looking at section VMAs? If one loadable section has a VMA of 0 then we can't discard debug info with low_pc == 0. If no section lives at address 0 then low_pc == 0 implies that the relocations for this info couldn't be applied because the code has vanished. I'm sure I missed somethnig in the general case, but I've added something like this as a post-load pass in a target_so_ops I implemented some time ago and it worked well. Fred.