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?

So what do you think the next steps are to move forward on this issue?

Did you have some expectations on who would do this translator work?

From your discussion it sounded like some of these issues were more general than just instruction tracing.
Are there plans to do any of that work?

Frank Ch. Eigler wrote:
Hi -

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

Yes, it was a good proof-of-concept of using utrace as the instruction-stepping infrastructure.

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

I believe we do need proper translator-side support for this feature, beyond what the tapset-only prototype provides. We need end-user scripts using itrace should not to have to use embedded-c code, and we need the implementation to be robust (i.e., not require users to match each "turn on itrace for pid PID" with "... off ...".

The first pair of probe point extensions listed in

  probe process(PID).itrace { }
  probe process(PID).btrace { }   # block trace

should be reasonably easy to implement.  The embedded-C code currently
in the tapset would become some mixture of code inlined by the
translator, or else copied into the runtime.  Adding dynamic
designation of target processes would be a small followup step.

Most of the discussion regarding the translator syntax changes was
beyond my understanding of SystemTap. [...]

We did go a bit far afield from the initial question, sorry about that.

- 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]