Messages in this thread | | | Date | Fri, 15 Sep 2006 10:57:29 -0400 | From | Karim Yaghmour <> | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 |
| |
Alan Cox wrote: > The gdb debug data lets you find each line and also the variable > assignments (except when highly optimised in some cases). Try > breakpointing there with kgdb and using "where"... A kgdb script is the > wrong way to do instrumentation but it does demonstrate the information > is already out there, automatically generated and self maintaining. > > You do need the gdb -g debug data, but equally if it was static you'd > need to recompile with the tracepoint because it would be off by > default, and there is a very small risk in both cases you'll disturb or > change the code behaviour/flow. ... > Thats why we have things like systemtap. > > 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"
Thanks for the explanation. But I submit to you that both explanations actually highlight the argument I was making earlier with regards to dynamic tracing (and gdb info in this case) actually require a non- expert to chase kernel versions and create appropriate appropriate scripts/config-info for the post-insertion of instrumentation, with the risks to kernel developers this may have (ex.: bug report to lkml from user claiming to have discovered problem in subsystem when, in fact, trace point by external maintainer was ill-chosen.)
Cheers,
Karim - 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/
| |