This is the mail archive of the systemtap@sourceware.org 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: Some newbie questions




On 08/09/2016 02:25 PM, Mark Wielaard wrote:
On Tue, Aug 09, 2016 at 09:51:22AM +0300, Avi Kivity wrote:
On 08/08/2016 05:58 PM, David Smith wrote:
2) Your ubacktrace() call in the timer function isn't going to report
what you want. At that point, you aren't running in the context of the
process, you are running in the context of whatever kernel thread is
running the timer. I'm really sure what a user backtrace will report at
that point, but it certainly won't be useful.
Actually I got good backtraces when I instrumented a task to spin for 100ms.
I also got some bad traces, but did not investigate more.
stap does indeed try to make this work even from a kernel context.
See runtime/stack.c:

/** Gets user space registers when available, also sets context
  * full_uregs_p if appropriate.  Should be used instead of accessing
  * context uregs field directly when (full) uregs are needed from
  * kernel context.
  */
static struct pt_regs *_stp_get_uregs(struct context *c)

But it might indeed depend on architecture and timer probe used.



I note that pid()/tid() also kept working. A happy coincidence maybe (the thread was not switched out). Maybe a per-thread timer can be added.

I'm surprised this didn't come up before. Trying to find out why a function which is usually fast and very rarely slow seems to be a good fit for systemtap.


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