This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: user instruction tracing patch?

Did you have any comments on the actual content of my patch?

Did you want to resolve the translator syntax changes to support instruction tracing first?

Most of the discussion regarding the translator syntax changes was beyond my understanding of SystemTap. It sounded like some of the issues were broader than just instruction tracing. Did you come to any consensus on what translator changes should be made?

Frank Ch. Eigler wrote:
Hi -

   probe program("/bin/vi").function("malloc")  { }

would be a request to probe all running (and forseeably, any future)
copies of vi. To filter further, I imagine additional qualifiers such
as ".pid(NUM)", ".uid(NUM)". These are all to identify the potential
probing target processes.
In the above examples, if NUM could be a variable name, then I think
we're in business... especially if it could be a set of pids or uids

Well, it depends how variable that data is. Another way to think about it is to think of the probe point type of specification as "additive", and as conditionals as "subtractive". If the data is fixed at/near startup time, then we can "add" probes only to the targeted processes and not bother any of the others. If the data is highly variable, it may be more appropriate to designate probes in them all, and "subtract" out the uninteresting ones on the fly by means of dynamic disabling conditions.

- FChE

Dave Nomura
LTC Linux Power Toolchain

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]