[lkml]   [2006]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    Ar Gwe, 2006-09-15 am 10:35 -0400, ysgrifennodd Karim Yaghmour:
    > Care to explain how I can use to implement the equivalent of this:
    > @@ -1709,6 +1712,7 @@ switch_tasks:
    > ++*switch_count;
    > 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). 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.

    > Also, care to explain how kprobes can be used to access same data
    > without having to actually customize a probe point for every binary?

    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"


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-09-15 16:39    [W:0.039 / U:2.996 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site