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

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

I have explained to you how the return value of dwfl_module_addrsym ()
works. 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.



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