This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 16 Nov 2012 18:02:11 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
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?
bzip2 -dvk backtrace.ppc64.*.bz2
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
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 4] .text PROGBITS 00000000100001e0 0001e0 081008 00 AX 0 0 32
 .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.
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
> 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).