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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 16 Nov 2012 23:16:12 +0100, Mark Wielaard wrote:
> I might be mixing up the ".name" vs "name" symbols.
> So symbols with the function name (without the dot) have values that point
> to the function descriptors?

Yes.

> Are the .name symbols also present,

Not in the file.

> and is their value the entry address of the function?

Yes.


But there is more confusion to it as DWARF symbols do not contain the dot but
they point to the code entry address (like the ELF dot symbols do).

elfutils cannot / should not change anything with that, this is established
ppc64 ABI (+binutils/gdb also behave that way):
	http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES


> OK, so, you want to translate a code address to a function symbol name.

Yes.


> I'll look at the bactrace example program to see how exactly you are
> invoking and using the result of dwfl_module_addrsym ().

            symname = dwfl_module_addrname (mod, pc_adjusted);


> I assume the name you are printing is what you would like the return value
> of dwfl_module_addrsym () to be?

Yes.


> Is there a reason you prefer the dot-name like '.main' instead of the plain
> function name 'main'?

elfutils cannot / should not change anything with that, this is established
ppc64 ABI (+binutils/gdb also behave that way):
	http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES


> Is that just for ppc64?

Yes; maybe there exist function descriptors for other archs, I do not know,
I also do not know what symbols naming convention would such non-ppc64 arch use.


> > For example for '.main' the code address is 0x1000115c but
> > 	readelf -Wa backtrace.ppc64.exec
> > says
> > Section Headers:
> >   [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
> >   [ 4] .text             PROGBITS        00000000100001e0 0001e0 081008 00  AX  0   0 32
> >   [24] .opd              PROGBITS        00000000100b4c38 0a4c38 0033f0 00  WA  0   0  8
> > Symbol table '.symtab' contains 1794 entries:
> >    Num:    Value          Size Type    Bind   Vis      Ndx Name
> >   1357: 00000000100b4d18    44 FUNC    GLOBAL DEFAULT   24 main
> 
> You say '.main' above, but you show here the symbol with the name 'main'.

Yes, because its value 0x100b4d18 belongs to .opd, therefore the ELF symbol
'main' is the function descriptor, therefore it should not have any dot.


> Is there also a symbol with the name '.main' in the table?

No.  '.main' is only synthetic in-memory symbol generated by bfd/ .


> > Without .opd content there is no way to resolve 0x1000115c to any symbol.
> 
> OK, I assume there is no symbol with '.main' in the table then.

Right.


> In general elfutils/libdwfl just works
> with plain ELF symbols. There is no concept of synthetic symbols.

This has to change; as long as ppc64 is supported.


> OK, so there is only the plain function name symbol, and never (?) a
> dot-function symbol then in the ELF symbol tables?

Right.


> I was thinking you would just want to return a different name and/or
> tweak the ELF symbol value that was returned by dwfl_module_addrsym ().

In fact it sometimes happens, you can see:
> # 0 0x10007fa8          __vmx__sigsetjmp_ent      | # 0 0x10007fa8          .raise

Symbol table '.symtab' contains 1794 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
   180: 0000000010007bc4     0 NOTYPE  LOCAL  DEFAULT    4 __vmx__sigsetjmp_ent

As __vmx__sigsetjmp_ent symbols has no size elfutils used it as a fallback when
no other better symbol was found.

So in some cases dot-symbols aware elfutils return different symbol name while
former elfutils returned also some (but different) symbol.


> But you want to return names and symbols for (address) values that are
> not actually in the symbol table.

Right.


> I have to think a bit more about that. It seems that means we would
> return some "fake" symbol results. So for an example, where we have
> a code address (x) which value does not fall inside any of the ELF
> symbols symbols in the module (mod) table,

You can never say "inside any of the ELF symbols", there are symbol priorities

libdwfl/dwfl_module_addrsym.c
              /* Return GELF_ST_BIND as higher-is-better integer.  */
              inline int binding_value (const GElf_Sym *symp)

where the "better" symbols override the "worse" symbols.  When the "better"
dot symbol is missing elfutils still can use some "worse" symbol instead.


> what would you expect to be
> a) The return value

Symbol name of the function descriptor with added leading dot.

> b) The values filled in for GElf_Sym *sym

The function descriptor symbol with patched in value to be the code entry
address.

> c) The value of GElf_Word *shndxp

Appropriately adjusted with artificial looked up content for the new symbol
value.

> when calling dwfl_module_addrsym (mod, x, &sym, &shndxp)?

Exactly like what this patch returns.

My current code uses only the return value (name) so I do not mind much about
the other content.  I find all the other content to be valid and possibly
needed in some cases but as I said I do not mind about the other content.


Thanks,
Jan