should minimal symbols be able to force lookup_symbol to return NULL?

should minimal symbols be able to force lookup_symbol to return NULL?

[David Carlton]

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.

Is this a desirable property to preserve?  Some versions of my
proposed rewrite to lookup_symbol_aux break that property (not on
purpose, I just hadn't realized that lookup_symbol_aux had that
property); now I'm worried that that is a mistake.

Specifically, I'm willing to believe that if we have a global minimal
symbol without a corresponding global symbol (presumably from a file
compiled without -g), then lookup_symbol_aux should never search the
static blocks.  After all, searching the static blocks is more of a
hack to try to hallucinate something useful to do if we can't do the
right thing, and in this situation it seems like the right thing to do
would be to try to extract information from the appropriate minimal
symbol.

But I don't know enough about the callers of lookup_symbol to be sure
here: are any of them persistent enough to search minimal symbols if
lookup_symbol returns null?  Actually, maybe I can answer that myself:
decode_line_1 does seem to do that, and it might not be the only such
caller.

Also, another issue: say that minsym lookup discovers a global minimal
symbol without a corresponding global symbol.  (And say that we're in
the non-HP case.)  Assuming that we agree that we shouldn't search for
a static symbol, then should we do a global psymtab search or not?  If
you think we shouldn't do a global psymtab search, do you say that for
optimization reasons or semantic reasons?

Currently, we don't do the global psymtab search (unless we're in the
HPPA case, in which case the minsym search happens much later).  I'd
be willing to believe that the current behavior arises from claiming
that symbol tables "should" never have a minimal symbol without a
symbol but with a partial symbol, so we might as well optimize out the
partial symbol search (which can be expensive), except that maybe
HP-generated symbol tables can lead to situations where this doesn't
work and where you really do need to do the partial symbol search as
well.

Any comments on this would be appreciated.  Right now I'm leaning
towards allowing global minimal symbol lookup to cancel static symbol
lookups, and I'm waffling on allowing it to cancel global partial
symbol lookups in the non-HP case.

David Carlton
carlton@math.stanford.edu

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[David Carlton]

On 28 Oct 2002 11:16:31 -0800, David Carlton <carlton@math.Stanford.EDU> 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.

David Carlton
carlton@math.stanford.edu

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[Jim Blandy]

David Carlton <carlton@math.stanford.edu> writes:
> On 28 Oct 2002 11:16:31 -0800, David Carlton <carlton@math.Stanford.EDU> 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.

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[David Carlton]

On 04 Nov 2002 15:53:43 -0500, Jim Blandy <jimb@redhat.com> said:
> David Carlton <carlton@math.stanford.edu> writes:
>> On 28 Oct 2002 11:16:31 -0800, David Carlton <carlton@math.Stanford.EDU> 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.

Oh, good.

> 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? 
>    */

Right.  Though, like Rich, I'm also vaguely worried about the Fortran
comment that comes later.

> Perhaps we should remove the HPUXHPPA conditional, and just do it
> the HPUXHPPA way all the time.

I've got some plausible scenarios which might allow both the HPUXHPPA
and non-HPUXHPPA cases to work without #ifdefs and which would allow
minsyms to be used as a speed optimization without affecting
correctness.  Basically, what they boil down to is keeping the minsym
check in its non-HPUXHPPA location, but making sure that it never
returns a NULL result; since that's what the above comment is
complaining about, it seems plausible that that would allow us to
remove the HPUXHPPA #ifdef.

I'll wait until my first stab at refactoring (which, I hope, preserves
the current behavior exactly) (well, almost exactly: there's one or
two changes which I think of as bugfixes, but it's quite careful about
control flow) gets approved before I submit an RFA for that.
Certainly I'm glad that Joel has appeared and is willing to run
proposed changes through the testsuite on HP/UX machines.

David Carlton
carlton@math.stanford.edu

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[Elena Zannoni]

David Carlton writes:
 > 
 > I'll wait until my first stab at refactoring (which, I hope, preserves
 > the current behavior exactly) (well, almost exactly: there's one or
 > two changes which I think of as bugfixes, but it's quite careful about
 > control flow) gets approved before I submit an RFA for that.
 > Certainly I'm glad that Joel has appeared and is willing to run
 > proposed changes through the testsuite on HP/UX machines.
 > 

I sent out a reply last night. 
http://sources.redhat.com/ml/gdb-patches/2002-11/msg00026.html

Elena


 > David Carlton
 > carlton@math.stanford.edu

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[David Carlton]

On Mon, 4 Nov 2002 17:18:17 -0500, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:

>> I'll wait until my first stab at refactoring (which, I hope, preserves
>> the current behavior exactly) (well, almost exactly: there's one or
>> two changes which I think of as bugfixes, but it's quite careful about
>> control flow) gets approved before I submit an RFA for that.
>> Certainly I'm glad that Joel has appeared and is willing to run
>> proposed changes through the testsuite on HP/UX machines.
>> 

> I sent out a reply last night. 
> http://sources.redhat.com/ml/gdb-patches/2002-11/msg00026.html

Yes, I saw it, thanks!  I just didn't have time to respond to it
properly yet: my actual job has rudely intervened.  (Plus, Michael
Snyder was kind enough to invite me over to Red Hat today.)  But I'm
almost done entering in homework grades, so hopefully I'll be able to
come up with a proper response later today; if not today, tomorrow.

David Carlton
carlton@math.stanford.edu

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[Elena Zannoni]

David Carlton writes:
 > On Mon, 4 Nov 2002 17:18:17 -0500, Elena Zannoni <ezannoni@redhat.com> said:
 > > David Carlton writes:
 > 
 > >> I'll wait until my first stab at refactoring (which, I hope, preserves
 > >> the current behavior exactly) (well, almost exactly: there's one or
 > >> two changes which I think of as bugfixes, but it's quite careful about
 > >> control flow) gets approved before I submit an RFA for that.
 > >> Certainly I'm glad that Joel has appeared and is willing to run
 > >> proposed changes through the testsuite on HP/UX machines.
 > >> 
 > 
 > > I sent out a reply last night. 
 > > http://sources.redhat.com/ml/gdb-patches/2002-11/msg00026.html
 > 
 > Yes, I saw it, thanks!  I just didn't have time to respond to it
 > properly yet: my actual job has rudely intervened.  (Plus, Michael
 > Snyder was kind enough to invite me over to Red Hat today.)  But I'm
 > almost done entering in homework grades, so hopefully I'll be able to

Ah, fail them, fail them all! :-)

 > come up with a proper response later today; if not today, tomorrow.

No problem. I thought it got lost, I had some mail glitches recently.

Elena


 > 
 > David Carlton
 > carlton@math.stanford.edu

Re: should minimal symbols be able to force lookup_symbol to return NULL?

[David Carlton]

On Mon, 4 Nov 2002 17:51:09 -0500, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:

>> But I'm almost done entering in homework grades

> Ah, fail them, fail them all! :-)

Geez - I guess I should be happy if you ever approve any part of a
patch of mine, huh?  :-)

David Carlton
carlton@math.stanford.edu