From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24255 invoked by alias); 20 Jun 2006 12:33:24 -0000 Received: (qmail 24243 invoked by uid 22791); 20 Jun 2006 12:33:23 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 20 Jun 2006 12:33:15 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-03.spheriq.net with ESMTP id k5KCXBSQ015128 for ; Tue, 20 Jun 2006 12:33:12 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 k5KCX23I003177 for ; Tue, 20 Jun 2006 12:33:08 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 k5KCWxTI008885 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 20 Jun 2006 12:33:01 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 861F0DA46; Tue, 20 Jun 2006 12:32:41 +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 5154247517; Tue, 20 Jun 2006 12:32:21 +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 CHS81692 (AUTH "frederic riss"); Tue, 20 Jun 2006 14:32:13 +0200 (CEST) Subject: Re: Problems with startup code symbols (Copious warnings) From: Frederic RISS To: Daniel Jacobowitz Cc: Jim Blandy , Steven Johnson , gdb@sources.redhat.com In-Reply-To: <20060620122112.GA20079@nevyn.them.org> References: <4487C21F.2090907@sakuraindustries.com> <44881434.2040207@sakuraindustries.com> <1150704956.2480.65.camel@crx549.cro.st.com> <20060620122112.GA20079@nevyn.them.org> Content-Type: text/plain Date: Tue, 20 Jun 2006 12:33:00 -0000 Message-Id: <1150806737.2480.71.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/msg00136.txt.bz2 On Tue, 2006-06-20 at 08:21 -0400, Daniel Jacobowitz wrote: > On Mon, Jun 19, 2006 at 10:15:56AM +0200, Frederic RISS wrote: > > 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. > > The problem is that this only works for binaries which _either_ use > linkonce sections or code at zero. A binary with both would still not > work very well. Of course. But I don't see any non-embedded binary with a section loaded at NULL. And I don't see much embedded bootcode needing linkonce sections. > Is that an improvement? I guess so. It's certainly better than the current HAS_RELOCS check.