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. > 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... -- 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
