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

Mark Wielaard mjw at redhat.com
Fri Nov 16 22:16:12 UTC 2012


On Fri, Nov 16, 2012 at 06:02:11PM +0100, Jan Kratochvil wrote:
> On Fri, 16 Nov 2012 14:31:53 +0100, Mark Wielaard wrote:
> > On Tue, 2012-11-13 at 16:18 +0100, Jan Kratochvil wrote:
> > > > (At least SystemTap assumes b) symbols areavailable in ET_REL files.)
> > > 
> > > Such symbols are available in every ET_* file.
> > 
> > Interesting. I thought the linker removed the dot-symbols.
> > But I don't have a ppc64 setup around to check.
> 
> I have verified now on RHEL-5.8 and F-16 that ET_REL looks exactly like
> ET_EXEC, that is the .symtab symbols contain function descriptor addresses
> from .opd and .opd is relocated to the .text code addresses.

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? Are the .name symbols also present, and is
their value the entry address of the function?

> > I have to admit that I am still a little unclear on what problem exactly
> > you are fixing. Could you give an example?
> 
> cd tests
> bzip2 -dvk backtrace.ppc64.*.bz2
> ./backtrace ./backtrace.ppc64.{exec,core}
> No DWARF information found                        <
> 0x10000000      0x100c0000      [exe]               0x10000000      0x100c0000      [exe]
> 0xfffa3000000   0xfffa3010000   linux-vdso64.so.1   0xfffa3000000   0xfffa3010000   linux-vdso64.so.1
> TID 54659:                                          TID 54659:
> # 0 0x10007fa8          __vmx__sigsetjmp_ent      | # 0 0x10007fa8          .raise
> # 1 0x10008370 - 1      __vmx__sigsetjmp_ent      | # 1 0x10008370 - 1      .abort
> # 2 0x10001344 - 1      (null)                    | # 2 0x10001344 - 1      .sigusr2
> # 3 0xfffa3000418       __kernel_sigtramp_rt64      # 3 0xfffa3000418       __kernel_sigtramp_rt64
> # 4 0x10007fa8          __vmx__sigsetjmp_ent      | # 4 0x10007fa8          .raise
> # 5 0x10001368 - 1      (null)                    | # 5 0x10001368 - 1      .raisesig
> # 6 0x10001390 - 1      (null)                    | # 6 0x10001390 - 1      .jmp
> # 7 0x100013ec - 1      (null)                    | # 7 0x100013ec - 1      .stdarg
> # 8 0x1000140c - 1      (null)                    | # 8 0x1000140c - 1      .child
> # 9 0x1000115c - 1      (null)                    | # 9 0x1000115c - 1      .main
> #10 0x10001610 - 1      (null)                    | #10 0x10001610 - 1      .generic_start_main

OK, so, you want to translate a code address to a function symbol name.
I'll look at the bactrace example program to see how exactly you are
invoking and using the result of dwfl_module_addrsym (). I assume the
name you are printing is what you would like the return value of
dwfl_module_addrsym () to be? Is there a reason you prefer the dot-name
like '.main' instead of the plain function name 'main'? Is that just
for ppc64?

> > Where did you get the address
> > from that you call dwfl_module_addrsym () on and why are you not
> > satisfied with getting the ELF symbol that address lies inside?
> 
> I get code address but that symbol points to the function descriptor.
>
> 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'.
Is there also a symbol with the name '.main' in the table?

> 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.

> > So there are two symbols available for each function on ppc64. One with
> > the name of the function that points to the address of the descriptor.
> > And one, with the name of the function prefixed with a dot, that points
> > to the actual function entry.
> 
> Just from what I have checked so far the second symbol is always only
> generated at runtime, it is never stored in the ELF file.
> 
> 
> bfd/elf64-ppc.c
> ppc64_elf_get_synthetic_symtab
>               s->flags |= BSF_SYNTHETIC;

Aha, that is probably where some of my confusion comes from.
I know very little about BSF. In general elfutils/libdwfl just works
with plain ELF symbols. There is no concept of synthetic symbols.

> > I am wondering which symbol is currently
> > being returned for dwfl_module_addrsym ()
> 
> Always only the first one.  When asked for the second one it fails to find any
> symbol.

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

> > and which one is returned with > your proposed change.
> 
> Both kinds are returned, depending on the address.  Addresses of the symbols do
> not overlap so the addr->name mapping is always unique (as long as we talk
> about the first vs. second kind of ppc64 symbols).
> 
> > My confusion might come from not knowing whether
> > or not both symbols are always available in all cases.
> 
> Without the first kind symbol one cannot generate the second one kind of
> symbol.  And the second one is available only if the .opd section is present.

Now I finally understand, I hope.
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 ().
But you want to return names and symbols for (address) values that are
not actually in the symbol table.

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, what would you expect to be
a) The return value
b) The values filled in for GElf_Sym *sym
c) The value of GElf_Word *shndxp
when calling dwfl_module_addrsym (mod, x, &sym, &shndxp)?

Thanks,

Mark


More information about the elfutils-devel mailing list