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

Jan Kratochvil jan.kratochvil at redhat.com
Fri Nov 16 17:02:11 UTC 2012


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



> 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

Without .opd content there is no way to resolve 0x1000115c to any symbol.


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


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


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


> Yes, but it isn't really a special case for ppc64. They really are
> slightly different things. Currently dwfl_module_addrsym () is about
> low-level ELF symbol lookup by address. But what you really want is
> function name lookup by address. Which is a slightly higher-level
> concept. So I don't think it is strange to have separate interfaces for
> it. You could even make it (optionally) do demangling, which
> 'dot-stripping' kind of is.

OK, that makes sense that for example demangling is a different kind of output.

Still for the ppc64 resolving case there is no ambiguity of the ouput, instead
of the second kind of symbol there is never any other symbol valid.
Just that the second kind of symbol is "synthetic" (bfd BSF_SYNTHETIC).


Thanks,
Jan


More information about the elfutils-devel mailing list