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 _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
