Re: [RFA]: Fix partial symbol lookups

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

Dan, have you looked at the HPUXHPPA defines in lookup_symbol ?
These make me believe that the HP reader indeed needs lookups on partial
symbols.

In this case, you have a problem when lookup_symbol is called with e.g.
overload1arg(int) (when we want to set a breakpoint at the function in
cplusfuncs).

As lookup_symbol_aux has no access to the mangled name, a lookup in the
partial symbols will fail, as you are looking for a demangled name in the
mangled names.
The previous version of lookup_partial_symbol (before your changes) would
have found both mangled and demangled names.


Your guesses are as good as mine, but before touching the HP code or 
continuing with speculations on how it should work or not, you'd better
ask someone who is familiar with the HP code.


I am really getting tired of arguing with you over all these issues.
Your 2000-10-12 changes _are_ broken, and I am not yet convinced that we will
really get away with your simplistic assumptions.

As a starter, the problems mentioned in
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00230.html
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00247.html
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00248.html
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00220.html
are still not addressed. I'd be curious how you intend to solve the
`maint check' problem, for example.

While looking at all the issues, I am also wondering, if the usage
of current_language->la_language in lookup_symbol will not cause problems
further down the road. What happens if execution stops in a C frame and you
want to access C++ information ?

> "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:
> 
> > > Daniel Berlin wrote:
> > > 
> > > > Correct.
> > > > But this never worked since 1994 anyway, since psymbols have no
> > > > demangled name in them.
> > > > :)
> > > 
> > > Good catch!  I too remember the comments that imply that
> > > mangled names are in there, and have assumed they were true.
> > 
> > They were not true from 1994 - Dec 1998 and I should be blamed that I
> > didn't remove the code and comment when I removed the demangling of 
> > partial symbols back in 1994, my sincere apologies.
> > 
> > > > I also corrected lookup_partial_symbol to binary search the global
> > > > table, regardless of language, since this is the part that had led me
> > > > to believe it had demangled names in it in the first place. 
> > > 
> > > Are you SURE that NO language puts mangled names in?
> > > If so, then this should be a big improvement.
> > 
> > I just double checked once again. 
> > add_psymbol_to_list (which is used by most symbol readers) calls 
> > SYMBOL_INIT_LANGUAGE_SPECIFIC (&psymbol, language), which sets the demangled
> > name to NULL.
> > 
> > But wait, the HP patches reintroduced the demangling of partial symbols
> > for their symbol reader (look for add_psymbol_with_dem_name_to_list).
> 
> This shouldn't make a difference, unless it's using the demangled name
> as the symbol name, rather than using SYMBOL_INIT_DEMANGLED_NAME (IE
> the right way is so the demangled name is the demangled name, the symbol name is the
> mangled name)
> > 
> > This is really bad, as GDB now has to cope with the presence and non-presence
> > of demangling in partial symbols. I'd be very reluctant to reintroduce
> > the demangling of partial symbols for all other symbol readers, instead
> > someone should fix the HP reader to not need the demangling of partial
> > symbols.
> 
> It shouldn't.
> 
> > 
> > I am now afraid that we have to back out all 2000-10-12 Dan Berlin changes,
> > to get a reliably working (and perhaps sometimes slower) GDB again.
> > 
> 
> No, we don't.
> Unless they are using the demangled name as the symbol name, which is
> incorrect anyway.
> As long as they have the mangled name, it'll be found in a partial
> symbol lookup just the same as it would be found elsewhere.
> IE it won't find more or less symbols than it would using any other
> debug format.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de