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