This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 11 Dec 2012 11:41:46 +0100
- Subject: 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
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.