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