lkml.org 
[lkml]   [2008]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][RFC 2/23]: SCST core
    2008/12/16 Ingo Molnar <mingo@elte.hu>:
    >
    > * Frédéric Weisbecker <fweisbec@gmail.com> wrote:
    >
    >> 2008/12/16 Ingo Molnar <mingo@elte.hu>:
    >> >
    >> > * Frédéric Weisbecker <fweisbec@gmail.com> wrote:
    >> >
    >> >> > All the above functionality is almost what we need. The only thing
    >> >> > left, which I forgot to mention, is possibility to log also functions
    >> >> > return value on exit. This is what TRACE_EXIT_RES() in SCST does. Is
    >> >> > it possible to add those?
    >> >>
    >> >> I want to add that on the function graph tracer. That can be done pretty
    >> >> easily. The only problem comes with the type of the return value. Would
    >> >> this tracer be supposed to always return a 64 bits value regardless of
    >> >> the real typ of the value? There would be some pointless bytes on most
    >> >> return values. I don't know how to proceed for this problem.
    >> >
    >> > Things like mov ...,%eax are zero-extend so they'll zap the high 32 bits.
    >>
    >>
    >> That's right, but the problem occurs under 32 bits. The return values
    >> for 64 bits are in eax and edx. And most of the time, the high part
    >> (edx) will be junk.
    >
    > for wider types i'd suggest to just print the low bits. Most of the
    > interesting return types fit into machine word.
    >
    >> > The real problem are byte return values generated via things like:
    >> >
    >> > movb $1, %al
    >> >
    >> > those wont zero-extend, so you could get garbage in the output. One
    >> > approach would be to try a quick hack just to see how common a problem
    >> > this is.
    >>
    >>
    >> Yes, I will try something.
    >>
    >> > We could extract the return type from the debuginfo, hash it in a
    >> > read-mostly table and then look it up, but that seems complex both in
    >> > terms of build overhead and in terms of runtime overhead.
    >>
    >> I thought about it too and as you say it's rather complex. And thinking
    >> about non primitive types (like pid_t....) that would require a second
    >> pass of analysis to retrieve the corresponding primitive...
    >
    > structure returns would be rather evil to handle, agreed.
    >
    > Unrelated:
    >
    > it would be really nice if we could extend ftrace to trace system calls
    > and their parameters and return values. We used to have that in the
    > latency-tracer in -rt, and it was rather useful. Controlled by a
    > trace_option i guess - and blendable into any of the tracer outputs
    > (function tracer most notably).
    >
    > Explicit calls in the entry.S files would be OK for this - but maybe we
    > can get this via the tricky use of a TIF_ flags as well, to force the code
    > into the ptrace callbacks and then divert it for ftrace's pleasure?
    >
    > Ingo
    >

    I recently thought about making a syscalls tracer and only thought
    about the tracepoints. But that could be better to
    trace them and all the function they call with the function graph
    tracer. I think about the "graph" one because time of execution
    measure could be useful for the -rt development.

    I think that putting new calls on entryxx.S would be an overload and
    would overlap what already does ptrace on syscall entry/exit.
    So I like the idea of using the ptrace callbacks by manipulating the TIF_ flags.

    Yeah that's interesting. I will do that for 2.6.30 :-)
    --
    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/

    \
     
     \ /
      Last update: 2008-12-17 00:49    [W:6.066 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site