From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3839 invoked by alias); 4 Nov 2002 21:08:31 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3811 invoked from network); 4 Nov 2002 21:08:29 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 4 Nov 2002 21:08:29 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id gA4KriW17766; Mon, 4 Nov 2002 15:53:44 -0500 To: David Carlton Cc: gdb , Elena Zannoni Subject: Re: should minimal symbols be able to force lookup_symbol to return NULL? References: From: Jim Blandy Date: Mon, 04 Nov 2002 13:08:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00045.txt.bz2 David Carlton writes: > On 28 Oct 2002 11:16:31 -0800, David Carlton said: > > > Currently, it seems to me that, when lookup_symbol_aux is searching > > the minsyms, if it finds a minsym without a corresponding symbol, > > then lookup_symbol_aux will return NULL without proceeding on to the > > check of the static symtabs/psymtabs. > > This isn't true: it only sometimes does that (if either it can find a > symtab at the right address or if it wants to try a name lookup with > the mangled name). Sigh. This is a mess. Yeah. I don't think that's deliberate behavior, since it doesn't happen under any consistent circumstances. As far as I can tell, the minsyms are in lookup_symtab_aux strictly as a faster way to find the right psymtab: look up the minsym by name, get its address, find the psymtab that covers that address. This does an address range comparison per psymtab, instead of a hash probe. But we know that our psymtab address ranges are inaccurate at times (C++ can scatter a single CU's code across disjoint parts of the text segment), so this seems like a rotten approach. I suspect that HP found the same problem you have: look at Rich Title's comment below (starting with "RT:"): #ifdef HPUXHPPA /* Check for the possibility of the symbol being a function or a global variable that is stored in one of the minimal symbol tables. The "minimal symbol table" is built from linker-supplied info. RT: I moved this check to last, after the complete search of the global (p)symtab's and static (p)symtab's. For HP-generated symbol tables, this check was causing a premature exit from lookup_symbol with NULL return, and thus messing up symbol lookups of things like "c::f". It seems to me a check of the minimal symbol table ought to be a last resort in any case. I'm vaguely worried about the comment below which talks about FORTRAN routines "foo_" though... is it saying we need to do the "minsym" check before the static check in this case? */ Perhaps we should remove the HPUXHPPA conditional, and just do it the HPUXHPPA way all the time.