2008/12/16 Ingo Molnar <mingo@xxxxxxx>: > > * Frédéric Weisbecker <fweisbec@xxxxxxxxx> wrote: > >> 2008/12/16 Ingo Molnar <mingo@xxxxxxx>: >> > >> > * Frédéric Weisbecker <fweisbec@xxxxxxxxx> 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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
