From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14426 invoked by alias); 23 Apr 2002 19:10:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14415 invoked from network); 23 Apr 2002 19:10:34 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 23 Apr 2002 19:10:34 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA17456; Tue, 23 Apr 2002 12:10:33 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g3NJA0K09801; Tue, 23 Apr 2002 12:10:00 -0700 Date: Tue, 23 Apr 2002 12:10:00 -0000 From: Kevin Buettner Message-Id: <1020423191000.ZM9800@localhost.localdomain> In-Reply-To: Michael Snyder "Re: [RFA] Kill SOFUN_ADDRESS_MAYBE_MISSING (was Re: multi-arch TODO)" (Apr 23, 10:46am) References: <20020422.040949.16307644.davem@redhat.com> <1020422152449.ZM1373@localhost.localdomain> <20020423.030048.41805003.davem@redhat.com> <1020423164342.ZM9027@localhost.localdomain> <3CC59E0A.D9572914@redhat.com> To: Michael Snyder , Kevin Buettner Subject: Re: [RFA] Kill SOFUN_ADDRESS_MAYBE_MISSING (was Re: multi-arch TODO) Cc: "David S. Miller" , gdb@sources.redhat.com, gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00865.txt.bz2 On Apr 23, 10:46am, Michael Snyder wrote: > Kevin Buettner wrote: > > > > On Apr 23, 3:00am, David S. Miller wrote: > > > > > > Why don't all Linux targets define this? Do some binutils ports > > > > perform this optimization and others not? Or was there some bug > > > > in N_FUN/N_SO stabs in binutils and/or gcc that this is papering > > > > around? kevinb@cyghat.com is the one who added this to powerpc > > > > and i386 Linux. > > > > > > I haven't given it a lot of thought recently, but my opinion is that > > > the SOFUN_ADDRESS_MAYBE_MISSING code ought to be enabled everywhere. > > > The only downside that I can think of is that we lose the ability > > > to put a symbol at address 0. > > > > > > Sounds find to me, how about this patch? > > > > > > 2002-04-23 David S. Miller > > > > > > * config/i386/tm-i386sol2.h, config/i386/tm-linux.h, > > > config/powerpc/tm-linux.h, config/powerpc/tm-ppc-eabi.h, > > > config/sparc/tm-sun4sol2.h (SOFUN_ADDRESS_MAYBE_MISSING): Kill. > > > * dbxread.c, elfread.c, minsyms.c, mdebugread.c, symmisc.c, > > > symtab.h (whole file): Act as if SOFUN_ADDRESS_MAYBE_MISSING was > > > always defined, kill ifdefs. > > > > Yes, this is exactly what I had in mind. It looks okay to me, but it > > needs to be carefully considered and approved (or not) by the symtab > > maintainers. > > > > As noted earlier, the downside is that we lose the ability to put a > > symbol at address 0. This doesn't pose a problem for operating > > systems which'll never map part of the program at address 0, but there > > may be some embedded environments for which this is a concern. > > Replace "may be" with "almost certainly are". Agreed. I'm beginning to remember more about this now. Contrary to my previous statements in this thread, I don't think we really lose the ability to have symbols at address 0. We can still have them, but it's more work to figure out that they're at zero because the minimal symbols will be consulted to make the determination. Kevin