This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: kprobes problem
- From: Richard J Moore <richardj_moore at uk dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Baruch Even <baruch at ev-en dot org>, "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com
- Date: Mon, 14 Mar 2005 09:44:31 +0000
- Subject: Re: kprobes problem
- Sensitivity:
This is not an expected restriction. My guess is that's it been introduced
with this change from single-stepping in situ to the later method where we
single-step out-of-line and leave the break-point in place. From memory I
know we make special calculations for fixing up the EIP after the
single-step. We may have missed a case with the RET instruction. It
shouldn't be too difficult to fix.
- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072
Roland McGrath
<roland@redhat.
com> To
Sent by: Baruch Even <baruch@ev-en.org>
systemtap-owner cc
@sources.redhat "Frank Ch. Eigler" <fche@redhat.com>,
.com systemtap@sources.redhat.com
bcc
13/03/2005 Subject
03:17 Re: kprobes problem
It sounds like there may be a generic bug with "ret" instructions. These
are handled specially. It would be best if you could construct a test
(e.g. write a test module that inserts kprobes on test code you provide in
that same module) where you can figure out exactly what happens when the
probe should be executing the return. That is, where you know exactly
where you should have gone after that (perhaps you can do this by having
another probe at the proper return location), and ideally figure out where
you actually went instead (or if the problem is different from that
e.g. the stack contents being wrong).