public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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

  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).