This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

According to
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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]