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]

Re: uprobes and empty functions


On 11/02/2010 02:02 PM, Jim Keniston wrote:
> Thanks.  The only problem I see is that if setup_uprobe_post_ssout()
> rejects the instruction, you need to report that via printk().

OK, I added a printk report, ported it to uprobes "1", and pushed it out
as commit 33d60a8.  Let's hope I didn't break the world...

In testing it, I did find a problem still, but it seemed to be broken
before my changes too.  On i386, I get a SEGV while singlestepping on a
relative call, e8.  x86_64 works fine on such calls.  For example, a
snippet from stap's main():

 805292c: e8 2f cb 00 00    call   805f460 <_ZN17systemtap_sessionC1Ev>
 8052931: 89 5c 24 08       mov    %ebx,0x8(%esp)

$ stap -e 'probe process("stap").statement(0x805292c) { println(pp()) }'
-c 'stap -V' -gw
process("/usr/local/bin/stap").statement(0x805292c)
$ dmesg | tail -n2
stap_bf9546c3238d167e5f1c89b1a484391c_1030: systemtap: 1.4/0.148, base:
e2077000, memory: 25data/17text/1ctx/13net/8alloc kb, probes: 1
Task died at uprobe probepoint:  pid/tgid = 3003/3003, probepoint =
0x805292c

vs.

$ stap -e 'probe process("stap").statement(0x8052931) { println(pp()) }'
-c 'stap -V' -gw
SystemTap translator/driver (version 1.4/0.148 commit
release-1.3-209-ga44a7cb)
Copyright (C) 2005-2010 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR
TR1_UNORDERED_MAP
process("/usr/local/bin/stap").statement(0x8052931)


In both cases, our probe handler is running ok, but on the "call" the
app is segfaulting.  I found that uprobe_pre_ssout looks ok, but then
the next utrace callback we get is for a SIGSEGV (rather than our
singlestep SIGTRAP).  So all the post_ssout changes I made aren't even
in play here.

This happens on both 32-bit Fedora 13 and RHEL5, so uprobes1 and
uprobes2 are both affected.

The only other thing I could find is that this only seems to happen on
e8 calls with a positive displacement.  When negative, it seems ok, like on:

 80529b0: e8 8b cd ff ff    call   804f740
<_ZL15remove_temp_dirR17systemtap_session>

Any idea?


Josh


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