Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

[fche@redhat.com (Frank Ch. Eigler)]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> [...]
> > 
> >    		prepare_arch_switch(rq, next);
> > +		TRACE_SCHEDCHANGE(prev, next);
> >    		prev = context_switch(rq, prev, next);
> >    		barrier();
> 
> The gdb debug data lets you find each line and also the variable
> assignments (except when highly optimised in some cases). [...]

Unfortunately, variables and even control flow are quite regularly
made non-probe-capable by modern gcc.  Statement boundaries and
variables are not preserved.  There is an arms race within gcc to both
improve code optimization and its own "reverse-engineering" debugging
data generation, and the former is always ahead.

The end result is that there are many spots that we'd like to probe in
systemtap, but can't place exactly or extract all the data we'd like.
Really.

There are also spots that for other reasons cannot tolerate a fully
dynamic kprobes-style probe:

- where 1000-cycle int3-dispatching overheads too high
- in low-level code such as fault handling or locking, that, if probed
  dynamically, could entail infinite regress
- debugging information may not be available

This is the reason why I'm in favour of some lightweight event-marking
facility: a way of catching those points where dynamic probing is not
sufficiently fast or dependable.

> [...]
> All we appear to lack is systemtap ability to parse debug data so it can
> be told "trace on line 9 of sched.c and record rq and next"

Actually:

#! stap
probe kernel.function("*@kernel/sched.c:9") { printf("%p %p", $rq, $next) }

- FChE