This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/17638] New: Symbol resolution broken for PPC64 ABIv2
- From: "ananth at in dot ibm.com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 24 Nov 2014 12:06:44 +0000
- Subject: [Bug runtime/17638] New: Symbol resolution broken for PPC64 ABIv2
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17638
Bug ID: 17638
Summary: Symbol resolution broken for PPC64 ABIv2
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: runtime
Assignee: systemtap at sourceware dot org
Reporter: ananth at in dot ibm.com
PPC64 ABIv2 has a facility where a function can have a Global Entry Point (GEP)
and a Local Entry Point (LEP); the LEP is at an offset from the GEP and can be
gotten to programmatically from the Elf64_Sym.st_other field. See the ABIv2
specification for more details. See arch/powerpc/kernel/module_64.c and
ppc_function_entry@arch/powerpc/include/asm/code-patching.h for more details.
Kprobes at function entry need probes installed at the LEP. The symbol table
and DWARF entry_pc/high_pc encode only the GEP instead. This needs fixing.
stap -p3 -ve 'probe kernel.function("do_fork") { printf("Hello\n"); exit() }'
... resolves do_fork as:
} stap_dwarf_probes[] = {
{ .address=(unsigned long)0x283950ULL, .module="kernel", .section="_stext",
.probe=(&stap_probes[0]), },
};
nnr:~/kprobes # grep do_fork /boot/System.map
c0000000000a6920 T do_fork
nnr:~/kprobes # stap -g -ve 'probe
kernel.statement(0xc0000000000a6928).absolute {printf("here\n") exit()}'
Pass 1: parsed user script and 102 library script(s) using
40256virt/33408res/5504shr/27072data kb, in 280usr/0sys/285real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s)
using 41216virt/35584res/6656shr/28032data kb, in 10usr/0sys/8real ms.
Pass 3: translated to C into
"/tmp/stapVEC1GH/stap_9c9d5bee16716aeedfab6219de368bd7_1067_src.c" using
41216virt/36032res/7104shr/28032data kb, in 10usr/0sys/9real ms.
Pass 4: compiled C into "stap_9c9d5bee16716aeedfab6219de368bd7_1067.ko" in
2160usr/100sys/3254real ms.
Pass 5: starting run.
here
Pass 5: run completed in 50usr/90sys/28905real ms.
Now, the real question is, where should this be fixed:
Elfutils?
Dwarf encoding of entry_pc/high_pc?
Or in the end consumer tools like stap/perf?
--
You are receiving this mail because:
You are the assignee for the bug.