[patch] Resolve ppc64 func descriptors as .func (via .opd)

Mark Wielaard mjw at redhat.com
Wed Dec 5 16:30:35 UTC 2012


On Wed, 2012-12-05 at 16:54 +0100, Jan Kratochvil wrote:
> On Wed, 05 Dec 2012 16:04:11 +0100, Mark Wielaard wrote:
> > No. Lets keep the shndxp/sym.shndx values as they are.
> 
> I do not mind, OK, I do not see what is shndxp/sym.shndx for the caller good
> for.

Good. Lets drop munging the shndxp/sym.shndx.

> Although the only idea of its use I have is that an application may have
> general logic for translation of ELF symbols from .opd section, in this case
> it would then try to double-translate such symbol (which would fortunately
> fail as VMA is then not from the .opd section anymore).

Could you give an example of what you have in mind here? If you think it
is relevant and/or might help me understand your use case.

> > Because then we change the contract of the function even more. Just
> > changing the st_value can be seen as how the function already works (we
> > consider resolving the function descriptor address just like adjusting
> > the st_value for the module location), but stretching it to do other
> > things too means we really should look into a new function for new
> > functionality.
> 
> I really do not mind any function contracts.

But keeping a sane/simple interface is important.

> I look only what is needed by the caller.

Then maybe you do need a completely different function after all?

> Caller needs a function which works universally for any address, returning any
> type of matching symbol, including resolving of function descriptors.

OK, I think we can provide that through dwfl_module_addrsym () if we let
the backend detect function descriptor symbols and return that
symbol/name if the address matches. That is what I propose you
implement.

> And I already tried to explain multiple times why the code symbols need to be
> differently named and that such different name is already defined by ppc64 ABI.

Indeed, I still don't see why this is relevant. The address will match
the function descriptor symbol and name. Not some synthetic code symbol.
As far as I can see the returned name and symbol information is what the
user wants/needs.

> If we have not found an agreement on that part then the next step is to get an
> approval from IBM.  I would find very unfriendly to break their ABI standard
> in common standard package without even letting them know.

Please do ask if you think that is helpful. I might be missing why it is
relevant/important. Having more opinions will certainly be welcome.

But I think just returning what is in the symbol table and not trying to
munch the returned values from what we already have is good enough.

Cheers,

Mark



More information about the elfutils-devel mailing list