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
http://en.wikipedia.org/wiki/Duck_typing
it has GElf_Sym type and it has ELF symbol content so it is ELF symbol.
According to
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES
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
dwfl_module_addrsym fix.
I have explained to you how the return value of dwfl_module_addrsym
()
works.
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).
Thanks,
Jan