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?

Hi, Roland -

On Wed, Nov 14, 2007 at 01:59:40PM -0800, Roland McGrath wrote:
> > Since utrace will provide the pt_regs structure, the probe handler
> [...]
> In general to access all registers you can't always use pt_regs directly;
> the details vary by machine.  You can get many of them on the common
> machines (x86, ppc).  A simple embedded-C tapset approach for each machine
> is certainly an easy place to start. [...]


> [...]
> >   probe process(PID).itrace if (condition) { }
> So this is special syntax constrained to just testing a script variable?
> Or it's any complex expression reducible to only reading global script
> variables?  Or what exactly?  

It will be defined carefully, something like this: the condition needs
to be an expression that uses only script-level global variables.

> [...]  But when its real use is to cause acts that change the value
> of evaluating the condition to hook into immediately changing the
> state of low-level tracing features that produce the probe hits,
> then I want to know exactly what the language semantics guarantees
> about the timely control of that state.

We discussed this briefly on the mailing list [1].  The provided
timeliness will have to depend on the kind of probe.  There will not
be spurious events (probe hits when the condition is false), but there
may be absent events (the condition is true but probe rearming could
not be accomplished quickly enough).  I expect that we'll use some
lightweight facility such as workqueues to minimize the time window.


> [...] If the variable is not otherwise used, wouldn't that compile to the same as:
>     probe process(PID).function("NAME") { enable process(PID).itrace; }
>     probe process(PID).function("NAME").return { disable process(PID).itrace; }

Yes, but the cases such as controlling many probes at once, or doing
so indirectly (e.g., setting individual values of an alternation),
makes the proposed syntax significantly more expressive, and IMO not
really more opaque.

> or whatever syntax explicit enable/disable has?

There isn't an explicit syntax for that at all.  It's partly in desire
to avoid having to invent it that we're implementing the conditional
widget instead.

- FChE

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