This is the mail archive of the elfutils-devel@sourceware.org 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.

Thanks,

Mark


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