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>
- Cc: "Sridharan, K" <k dot sridharan at intel dot com>, "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 18:27:09 -0800
- Subject: RE: architecture paper draft
Good point that new instructions are relatively rare in
kernel code. At least I hope so! I agree that in user
space the trap to kernel is the way to go.
Brad
-----Original Message-----
From: Stephen C. Tweedie [mailto:sct@redhat.com]
Sent: Friday, February 11, 2005 11:43 AM
To: Chen, Brad
Cc: Sridharan, K; William Cohen; Frank Ch. Eigler;
systemtap@sources.redhat.com
Subject: RE: architecture paper draft
Hi,
On Fri, 2005-02-11 at 19:20, Chen, Brad wrote:
> 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.
That would be an option, yes. But from a vendor perspective we
shouldn't be hitting new instructions in the kernel (where the build
environment is more controlled), only from user space. And in user
space, kprobes already need to trap into kernel space, so perhaps the
int3 mechanism is OK for that side of things.
--Stephen