From: Roland McGrath <roland@redhat.com>
To: Tim Bird <tim.bird@am.sony.com>
Cc: systemtap <systemtap@sourceware.org>
Subject: Re: Random ideas about systemtap dependencies
Date: Tue, 23 May 2006 20:35:00 -0000 [thread overview]
Message-ID: <20060523203400.1F21D180054@magilla.sf.frob.com> (raw)
In-Reply-To: Tim Bird's message of Tuesday, 23 May 2006 12:36:48 -0700 <44736450.7060601@am.sony.com>
A general answer is that systemtap is intended to have many flavors of
probes, with the level of things like kprobes being an implementation
detail used by some probes. The present prevalence of kprobes in the
implementation of systemtap probes will not necessarily always be the case.
Specifically, are you talking about compiling with -pg? I can see making
that work with a special-purpose mcount (a little per-machine work there)
that looks up PC locations in a table of probeable spots. I think the work
required in integrating that with the translator is mainly in getting all
the exact PC locations that mcount will be looking up. From the kernel
build one needs to glean this static list of potential probe sites, and
then jigger the translator to resolve each "entry" probe to the correct
statically chosen PC for the named function. With that, the existing
machinery for things like target variable access should do fine working
from the correct PC. Of course, only function entry probes can be
supported this way.
So in short, it's doable and fits fine into the larger scheme of things.
There is a fair bit of work you'd have to do, but it doesn't inherently
clash with what we're doing.
Thanks,
Roland
next prev parent reply other threads:[~2006-05-23 20:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-23 19:36 Tim Bird
2006-05-23 20:35 ` Roland McGrath [this message]
2006-05-23 20:47 ` Tim Bird
2006-05-23 20:55 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060523203400.1F21D180054@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=systemtap@sourceware.org \
--cc=tim.bird@am.sony.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).