Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: dberlin@redhat.com (Daniel Berlin)
Cc: msnyder@cygnus.com, jimb@cygnus.com,
	gdb-patches@sources.redhat.com, ezannoni@cygnus.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 08:29:00 -0000	[thread overview]
Message-ID: <200011161629.RAA06158@reisser.regent.e-technik.tu-muenchen.de> (raw)
In-Reply-To: <m3snorj4d7.fsf@dan2.cygnus.com>

> > The previous version of lookup_partial_symbol (before your changes) would
> > have found both mangled and demangled names.
> 
> Now this I take issue with.
> How could it possibly find demangled names, if it doesn't have access
> to them?
> lookup_partial_symbol didn't find demangled names before my patch on
> 10-12. It doesn't have the code to do so, as you pointed out yourself
> (because the SYMBOL_MATCHES_NAME is no better than the strcmp, since
> we have no access to demangled names), unless the symbol name was the
> demangled name, rather than the mangled name, which doesn't occur.

Not true.
There were no demangled names in partial symbols from most symbol readers,
_except_ for the HP reader, which we are currently discussing, and which
I discovered rather late in the day as well.
Before your change, lookup_partial_symbol fell back to a linear search
if it didn't find the symbol and had the chance to find the demangled symbol
via SYMBOL_MATCHES_NAME during the linear search.

> > 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. 
> 
> The first one includes a patch, as soon as it's approved, it'll be
> applied.

And which will have to be adapted to your patches. Which will mean more
work for me, now that I am responsible for fixing _your_ bug because _I_
submitted the RFA, right ?

> The second one points out things this patch fixes.

No, it contains an example which is not fixed after the infinite regression
gets fixed. Please read the message again and then try the example with
any combination of suggested fixes you like. It will not work.

> The third one is the same.

No, it points out another problem with `maint check'. Have you ever tried it
with your patches ?

> The fourth one has to do with makefile tweaking, so i have no clue
> what that has to do with anything.

Sorry, typo, I meant
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00250.html
I've also submitted a patch for that one though. It is the easiest to fix,
and it seems that I will have to take care of that one as well ?

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From dberlin@redhat.com Thu Nov 16 08:36:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: msnyder@redhat.com, jimb@cygnus.com, gdb-patches@sources.redhat.com, ezannoni@cygnus.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 08:36:00 -0000
Message-id: <m38zqj3mcb.fsf@dan2.cygnus.com>
References: <200011161222.NAA05985@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-11/msg00205.html
Content-length: 2046

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> 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.

And just for the record, this is wrong, and the source of many
annoying bugs i've tried to track down (such as where we would or wouldn't find a C++
operator symbol depending on when you tried to call
it. lookup_partial_symbol wouldn't find it, but lookup_symbol and
lookup_minimal_symbol would.).

I grabbed gdb-5.0 source, which certainly does not have my changes in
it, and lo and behold, it doesn't find demangled names in partial
symbols. Try it yerself if you like.

It's possible this is because of your change in 1994 to make partial
symbols no longer have demangled names.
But we certainly no longer find demangled names in partial symbols,
since at least 5 months before my changes.
In fact, I was actually of the impression that we weren't supposed to, since we
never have since as long as i've been working on GDB.
If lookup_partial_symbol is supposed to be able to find demangled
names, then it needs access to the demangled names, which partial
symbols don't have.
We'd either have to transform demangled names back into mangled ones,
or include demangled names in partial symbols, to have this work..

Alternatively, you could SYMBOL_INIT_DEMANGLED_NAME in
lookup_partial_symbol, before calling SYMBOL_MATCHES_NAME.

but SYMBOL_MATCHES_NAME won't ever see a demangled name on the partial
symbols, and thus, never find a demangled name.


--Dan




       reply	other threads:[~2000-11-16  8:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3snorj4d7.fsf@dan2.cygnus.com>
2000-11-16  8:29 ` Peter.Schauer [this message]
2000-11-16  8:44   ` Daniel Berlin
2000-11-16  9:06     ` Peter.Schauer
2000-11-16  9:16       ` Daniel Berlin
2000-11-16  8:56   ` Daniel Berlin
2000-11-16  9:02     ` Daniel Berlin
     [not found] <200011161222.NAA05985@reisser.regent.e-technik.tu-muenchen.de>
     [not found] ` <m38zqj3mcb.fsf@dan2.cygnus.com>
2000-11-16 11:01   ` Christopher Faylor
     [not found] <m3vgtqv60a.fsf@dan2.cygnus.com>
     [not found] ` <npbsvhzxm9.fsf@zwingli.cygnus.com>
     [not found]   ` <m3hf59izpl.fsf@dan2.cygnus.com>
2000-11-15  8:56     ` Michael Snyder
     [not found]       ` <m3g0ktkrjh.fsf@dan2.cygnus.com>
2000-11-15 11:19         ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200011161629.RAA06158@reisser.regent.e-technik.tu-muenchen.de \
    --to=peter.schauer@regent.e-technik.tu-muenchen.de \
    --cc=dberlin@redhat.com \
    --cc=ezannoni@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@cygnus.com \
    --cc=msnyder@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox