This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/19500] .callee test failures
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 25 Feb 2016 22:37:34 +0000
- Subject: [Bug translator/19500] .callee test failures
- Auto-submitted: auto-generated
- References: <bug-19500-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19500
--- Comment #2 from David Smith <dsmith at redhat dot com> ---
On ppc64, the debuginfo looks reasonable. In the 'reloc - probing shlib foo
.callees' case, what happens is that _caller_match() gets called in the probe
handler, returns false, so the handler exits early. With STAP_CALLEE_MATCHALL
defined in a couple of places, the test completely passes.
When the test fails in the 'reloc - probing shlib foo .callees' case, here's
what _caller_match() sees:
====
# stap -DDEBUG_SYMBOLS=1 -e 'probe
process("./reloc").library("libreloc.so").function("foo").callees {
printf("caller %s callee %s\n", usymname(ustack(1)), ppfunc()) }' -c "./reloc
; true"
_stp_do_relocation:73: found kernel _stext load address: 0xc000000000000000
_stp_kmodule_update_address:1052: module
stap_694ab5dbd3f37227c1a6bd579439c70_21670 special section .note.gnu.build-id
address 0xd00000000cbe9af4
_stp_kmodule_update_address:1065: module
stap_694ab5dbd3f37227c1a6bd579439c70_21670 section .symtab address
0xd00000000cc20000
_stp_kmodule_update_address:1065: module
stap_694ab5dbd3f37227c1a6bd579439c70_21670 section .text address
0xd00000000cbd0000
_stp_usermodule_check:833: build-id validation [21675
/root/rhel7.2/testsuite/libreloc.so] address=0x3fffb03d0000
build_id_offset=0x1a0
_stp_umod_lookup:153: found module /root/rhel7.2/testsuite/libreloc.so at 0x0
_stp_umodule_relocate:78: [21675] /root/rhel7.2/testsuite/libreloc.so, 968
_stp_umodule_relocate:95: address=3fffb03d0968
function___global__caller_match:545: addr 0x968, stack 0x3fffb03d0964, reloc
0x3fffb03d0968
#
====
(note that the code for the last debug print isn't checked in)
Since the stack address (0x3fffb03d0964) doesn't *exactly* match the relocated
address (0x3fffb03d0968), _caller_match() returns 0. But, as you can see in
this case, the 2 addresses are only off by 4 bytes. Perhaps our math isn't
quite right somewhere.
--
You are receiving this mail because:
You are the assignee for the bug.