This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/10512] STAP_PROBES don't work in c++ constructors/destructors
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 14 Aug 2009 09:05:01 -0000
- Subject: [Bug runtime/10512] STAP_PROBES don't work in c++ constructors/destructors
- References: <20090812145803.10512.mjw@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From mjw at redhat dot com 2009-08-14 09:04 -------
(In reply to comment #1)
> Created an attachment (id=4128)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4128&action=view)
> class testcase
>
> Testcase that shows the issue when compiled with:
> $ g++ -I includes/sys -o test cxxclass.cxx
>
/tmp/ccqveEm3.o:(.data._ZZN10ProbeClassC1ERiPKcE8labelval[ProbeClass::ProbeClass(int&,
> char const*)::labelval]+0x0): undefined reference to `.L21'
>
/tmp/ccqveEm3.o:(.data._ZZN10ProbeClassD1EvE8labelval[ProbeClass::~ProbeClass()::labelval]+0x0):
> undefined reference to `.L22'
> collect2: ld returned 1 exit status
Note that this testcase seems to show a somewhat different issue from what was
described in comment #1. The issue in the above is the reference to the computed
goto for the label in a constructor/destructor.
We have the computed goto reference assigned to a static variable initializer to
prevent inlining of the function that the probe is on (since we can only
reference and store one label address in the .probes section through the
preprocessor).
Interestingly just removing the computed goto reference seems to make g++ do the
right thing, even with optimizations. We get multiple duplicated probe name
addresses in the probes section:
#define STAP_UNINLINE_LABEL(label) \
- __extension__ static volatile long labelval __attribute__ ((unused)) =
(long) &&label
+ // __extension__ static volatile long labelval __attribute__ ((unused)) =
(long) &&label
$ stap -vvvvvv -L 'process("./test").mark("*")' 2>&1 | grep ^saw
saw .probes cons@0x40063b
saw .probes meth@0x40067b
saw .probes dest@0x4006b4
saw .probes cons@0x4006e8
saw .probes meth@0x400728
saw .probes dest@0x400766
saw .probes dest@0x4007a2
saw .probes dest@0x4007e4
stap doesn't know how to deal with that though, and currently only creates one
statement probe per name seen.
stap -vve 'probe process("./test").mark("cons") { printf("cons hit @0x%x\n",
uaddr()); }' -c ./test
[...]
probe main@/home/mark/src/systemtap/cxxclass.cxx.test.cxx:53
process=/usr/local/src/systemtap/test.orig reloc=.absolute section=.text pc=0x40063b
[...]
cons call: 64
meth call: 64 24
dest call: 42
cons call2: 24
meth call2: 24 40
dest call2: 42
cons hit @0x40063b
Also trying to reference the local args of the mark doesn't work:
semantic error: unable to find local 'arg1' near pc 0x40063b in
main(cxxclass.cxx.test.cxx) (alternatives: argc argv): identifier '$arg1' at
<input>:1:94
source: probe process("./test.orig").mark("cons") { printf("cons hit
@0x%x name=%s i=%d\n", uaddr(), $arg1, $arg2); }
As can be seen from the alternatives suggested only the variables of the
function into which the probe was inlined are visible.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10512
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.