Messages in this thread | | | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 | From | (Frank Ch. Eigler) | Date | 15 Sep 2006 13:08:29 -0400 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |