Re: [rfa] more lookup_symbol_aux_minsyms futzing

[Jason Molenda <jason-swarelist at molenda dot com>]

Hi David,

On Mon, Dec 23, 2002 at 10:21:12AM -0800, David Carlton wrote:
> Here's another patch involving lookup_symbol_aux_minsyms.  

We (Apple) shipped our latest devtools release based on the Octoberish
gdb top-of-tree and I spent a good bit of today tracking over this
same exactly section of code for a customer's problem.  I was going
to send out a note once I understood how it'd all happened, but it
sounds exactly like what you describe here.

It's been a good while since I've looked at this code, and my notes
from today's debugging are all at work, so please excuse any especially
dumb misstatements. :)  

lookup_symbol_aux is called with a C++ unmanged+mangled name,
lookup_symbol_aux_symtabs doesn't get a match because we've only
read in the psymtab at this point; lookup_symbol_aux_minsyms calls
lookup_symbol_aux with the mangled+mangled names as a last resort,
and something lame happened from there on (but I don't remember
exactly...) -- and eventually we call lookup_symbol_aux_psymtabs
with the mangled+mangled names -- lookup_partial_symbol gets passed
a mangled name, says there is a match because psymtabs have only
mangled names.  We parse in the symtab, then we do lookup_block_symbol
with the mangled name, but the lookup_block_symbol hash of the mangled
name doesn't match that of the unmangled name, so we issue the error

              error ("Internal: %s symbol `%s' found in %s psymtab but not in symtab.\n%s may be an inlined function, or may be a template function\n(if a template, try specifying an instantiation: %s<type>).",
                     block_index == GLOBAL_BLOCK ? "global" : "static",

It also seemed incorrect for lookup_symbol_aux to call
lookup_symbol_aux_minsyms before lookup_symbol_aux_psymtabs, but 
I'm guessing this is done on purpose based on this comment in your
patch -

> +	  /* We found a minimal symbol in spite of not finding a
> +	     symbol.  This probably means that the symbol in question
> +	     is in a partial symbol table that hasn't been loaded, but
> +	     it may mean that it's from code compiled without -g.
> +	     Partial symbol table searches are kind of expensive; if
> +	     the symbol corresponds to a function, we can find the
> +	     appropriate symtab more quickly by calling
> +	     find_pc_sect_symtab, so let's try that.  */
> +


The test case I have from the customer is a nice little thing but
it pulls in a big gop of Apple system libraries so I don't know
how easy it'd be to make a portable version.  At the very least,
I'll be looking at this tomorrow and should know better how we can
fix it up.

For what it's worth, everyone at Apple has been really excited by
the work you've been doing, David.  Anyone willing to wade into
decode_line_1 and do something other than increase entropy has my
respect. :-)

Jason