This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/5890] sys.stp andtestsuite/systemtap.syscall/sys.stp fail on 2.6.25 x86_64


------- Additional Comments From jistone at redhat dot com  2009-10-09 17:48 -------
(In reply to comment #8)
> selected inline instance of compat_sys_recvmsg
> entry-pc lookup (dwarf_entrypc dieoffset: 0x25c4f69) = 0xffffffff8048a9a4 (rc 0)
> selected function compat_sys_recvmsg
> probe compat_sys_recvmsg@net/compat.c:737 kernel reloc=.dynamic
pc=0xffffffff80489d5b
> entry-pc lookup (dwarf_entrypc dieoffset: 0x25c38d2) = 0xffffffff80489d5b (rc 0)

So I was right -- there's an inline and a full function.

> semantic error: not accessible at this address (0xffffffff8048a9a4):
identifier '$fd' at <input>:1:44
>         source: probe syscall.compat_sys_recvmsg { println($fd); }

And it is the inline that can't find $fd.  This is correct, in that we're doing
the best we can with bad debuginfo... :(

Since this is your own kernel, you could just patch that function with
attribute-noinline, or even compile with a VTA-enabled gcc to get better
tracking of inline vars.

This also makes me think that the syscall tapset is slightly broken.  We have
.return variants for almost all of them, but that can only work when they're not
inlined, so perhaps these should all be .call probes.  We would also probably
want syscall.socketcall enabled then, to cover this particular example that
could be inlined...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5890

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]