This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 11 Dec 2012 13:54:51 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Tue, 11 Dec 2012 11:41:46 +0100, Mark Wielaard wrote:
> On Tue, 2012-12-11 at 11:24 +0100, Jan Kratochvil wrote:
> > On Tue, 11 Dec 2012 11:13:37 +0100, Mark Wielaard wrote:
> > > I don't think dwfl_module_addrsym () really has anything to do with the
> > > ppc64 ABI
> > That is in fact the whole question to IBM, whether it has or has not.
> No. You are mixing things. You may certainly ask anybody how the
> dwfl_module_addrsym in libdwfl should work. And you may also certainly
> ask what a backtrace on ppc64 should look like. And it may very well be
> that someone from IBM has great input on both issues. But they are not
> the same issue.
They are the same.
dwfl_module_addrsym returns synthetic ELF symbol for the code entry point.
We do not have to call it synthetic ELF symbol but according to
it has GElf_Sym type and it has ELF symbol content so it is ELF symbol.
the type (GElf_Sym) and its content perfectly matches "entry point address".
While the standard only talks about NAME => ADDRESS implication one can IMO
assume an equivalence there and a class of symbols having ADDRESS should have
also that NAME.
> > But without resolving it yet I ask a different question to get more a picture
> > how your solution may work:
> > If elfutils had name -> address resolver (still without DWARF capability)
> > which address should be resolved for "raise"? Should be ".raise" also
> > resolved?
> Again this is a different question from how dwfl_module_addrsym ()
> works. It is a too generic question to know the precise answer now.
It is a very real question, if you reject the ABI compliance you are forcing
me to implement this name -> address ppc64 resolver. Otherwise in the future
one finds out one has to break the established elfutils naming to be able to
implement the name -> address ppc64 resolver.
Besides everything said above, when I see a symbol ".main" in GDB or binutils
one expects the elfutils will recognize the same symbol with the same value.
I can assure you that before I started working in RH I would (and I still do)
consider different symbol names/values between eu-addr2line and addr2line to
be a bug.
I think whatever way we ask the IBM ABI authority about the naming the answer
is clear, that the dot prefix should be present there.
> If in the symbol table that you use to resolve such a name -> address
> mapping dot-prefixed names are there then it probably will. Or maybe the
> architecture specific backend has some matching that (de)mangles the name
> before matching. We can discuss when we implement it.
Going to implement it although I find it a waste of time just to upstream this
> I have explained to you how the return value of dwfl_module_addrsym ()
Yes, it is a synthetic ELF symbol.
> That is just how it is. You might not agree, but creating
> artificial names or symbols is really not how it is supposed to work.
I do not see how to keep name+value compatibility with BFD and also how to
implement ABI compatible name -> address resolution (I find it even clear for
address -> name resolution but we have not found an agreement for it).