From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: gdb-patches@sourceware.org, bauerman@br.ibm.com, amodra@bigpond.net.au
Subject: Re: Shared library call problems on PowerPC with current binutils/gdb
Date: Sat, 03 May 2008 15:59:00 -0000 [thread overview]
Message-ID: <200805031538.m43Fce6B013612@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20080503152457.GA20531@caradoc.them.org> from "Daniel Jacobowitz" at May 03, 2008 11:24:57 AM
Daniel Jacobowitz wrote:
> On Sat, May 03, 2008 at 12:29:04AM +0200, Ulrich Weigand wrote:
> > Daniel Jacobowitz wrote:
> >
> > > This appears to work consistently, where by work I mean disassembly
> > > shows the @plt sym but breakpoints on the undecorated version work
> > > fine. I'm not sure exactly why; it may be luck.
>
> lookup_minimal_symbol_by_pc_section takes the last match in case of
> multiple matches. Minimal symbols are sorted by name. So malloc@plt
> always sorts after malloc. Subtle, but not luck exactly.
I see. Hmmm, we could do the same for versioned symbols and just
install two minsyms. For disassembly, we'd see the decorated name,
but searching for just the base name would find the function as well ...
> > > Hmm, thinking about this more, it probably won't work for your
> > > case after all. lookup_solib_trampoline_symbol_by_pc will return
> > > NULL if the first symbol we find is the text version.
> >
> > If we have two symbols, *both* need to be mst_solib_trampoline.
>
> Would that be true if we could search for a symbol with the
> appropriate type? Prefer the trampoline when trying to find a
> trampoline target, prefer the text symbol with the decorated name
> otherwise.
That's probably the best solution, right.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2008-05-03 15:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 2:38 Ulrich Weigand
2008-04-29 3:05 ` Daniel Jacobowitz
2008-04-29 15:59 ` Daniel Jacobowitz
2008-05-02 23:01 ` Daniel Jacobowitz
2008-05-02 23:25 ` Ulrich Weigand
2008-05-03 15:39 ` Daniel Jacobowitz
2008-05-03 15:59 ` Ulrich Weigand [this message]
2008-05-03 17:19 ` Daniel Jacobowitz
2008-05-14 18:25 ` Ulrich Weigand
2008-05-14 18:29 ` Daniel Jacobowitz
2008-05-14 21:38 ` Ulrich Weigand
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=200805031538.m43Fce6B013612@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=amodra@bigpond.net.au \
--cc=bauerman@br.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/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