This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: architecture paper draft
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: "Stephen C. Tweedie" <sct at redhat dot com>, "Sridharan, K" <k dot sridharan at intel dot com>
- Cc: "William Cohen" <wcohen at redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, <systemtap at sources dot redhat dot com>
- Date: Fri, 11 Feb 2005 11:20:05 -0800
- Subject: RE: architecture paper draft
New instructions: hopefully these won't happen very often.
When they do, they would only be a problem for systemtap if
they were in procedure prologues or epilogues, right? If we
did hit a new instruction at a probe point, we could just
refuse to instrument them until the tools catch up. These
probes would become unavailable; perhaps the script would
refuse to run.
Brad
-----Original Message-----
From: Stephen C. Tweedie [mailto:sct@redhat.com]
Sent: Friday, February 11, 2005 8:56 AM
To: Sridharan, K
Cc: William Cohen; Chen, Brad; Frank Ch. Eigler;
systemtap@sources.redhat.com
Subject: RE: architecture paper draft
Hi,
On Fri, 2005-02-11 at 16:28, Sridharan, K wrote:
> There are technologies available that figure out lengths of the X86
> instructions very well and many of these are part of commercial
products
> available in the market. If that is the only stumbling block to avoid
> excessive overhead, then we can see how to provide that technology.
How will that deal with new instructions? We'd have to deal with cases
where new toolchains are inserting enhanced but kernel-compatible
instructions into applications, and the kprobes aren't aware of them.
The technique of simply single-stepping over the replaced instruction
neatly avoids that problem.
If the use of branches is restricted to kernel probes, then that issue
is much less important, as we have control over the toolchain in that
case.
--Stephen