Hi Jan,
I looked a bit more into this and it looks like however we fix this
issue, we will break some assumptions. At least systemtap is not
prepared to handle extra symbols values in non-ET_REL files. I'll fix up
systemtap to be less strict because I think the current code isn't
really kosher to begin with. I haven't found any other users that make
special assumptions here. So hopefully we can still fix this
generically.
I do agree we want this fixed so that looking up a function by name
through dwfl_module_getsym matches what you get from dwfl_module_addrsym
and the other way around. So that addr2line or the new stack
functionality just works without needing special casing on different
arches that happen to use function descriptors sometimes. But...
> The mangling of names by prepending a dot is somewhat ugly and
requires
> lots of extra memory. Can't we just keep the proper name of the original
> symbol without the extra dot added. That would look much cleaner.
>
> Or more radical, do we even have to keep the old symbols? Can't we just
> adjust their st_value and section index and be done with it? That would
> simplify things a lot.
I find even better looking to display the symbol names capitalized.
It is a name of function so the capitalization makes sense.
I was joking now but this is exactly the same elf symbol name corruption you
suggest.
No, I suggest just NOT adding extra names, dot mangled, or not. But just
keep the function symbol names as is. Just resolve the values (which we
already adjust anyway so they map into Dwfl address space) without any
extra magic.
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES
exactly defines it:
For an externally visible function, the value of the symbol with the
same name as the function is the address of the function descriptor.
Symbol names with a dot (.) prefix are reserved for holding entry
point addresses. The value of a symbol named ".FN", if it exists, is
the entry point of the function "FN".
ppc64_init_symbols() generates synthetic ELF symbols. Those are ELF symbols.
Therefore they have to be compliant to the ppc64 ABI above.
Additionally even when dot-prefixed symbols may exist in the input file having
some different naming for the symbols would be a complete mess.
I did not expect we will continue this disagreement even when real ELF symbols
are generated now. Originally I wanted to Cc someone from IBM but I do not
see what to ask about, the ppc64 ABI spec is clear enough.
As I said before I don't think the ABI for object file link editor
really matters much in the case of the libdwfl interfaces. The don't
need extra real synthetic ELF symbols. If dot-prefixed symbols are
present as in ET_REL files just leave them alone (kernel modules are
special anyway). But adding lots of additional synthetic symbols to the
dwfl_module_*sym* calls where they didn't exist before really is not the
way to go. We really need something simpler.
What we have are functions that match function symbol names and values
to/from the Dwfl_Module address space layout. For that we already adjust
the values as found in the ELF files. All we need to do is resolve any
function descriptor entry values. We don't need to introduce an extra
synthetic symbol table for that.
I wrote a patch to just do that which is attached. I did keep your tests
and adjusted the expected outputs a little to remove the extra
dot-prefixed symbols. It probably needs a little more testing, but seems
to work just fine. I'll try it out with your ppc unwinder backend later.
Please take a look.
Thanks,
Mark