We already support implicitly saving $target variables at function entry for use in a .return probe (though bug #5899 debates when ->members should be read). There's a good idea in bug #5899 comment #4 to support saving arbitrary expressions as well. I quite like the example: probe FOO.return { println(gettimeofday_ns() - @entry(gettimeofday_ns())) } This @entry syntax is somewhat distinct from #5899, so I thought it should be its own bug. I think our traditional saved_var[tid()] mechanism could be adapted for this pretty easily. The newer method using the kretprobe data pouch (bug #5916) is a little tricker though, as it would need the types to be resolved a bit earlier than we do now.
(In reply to comment #0) > I think our traditional saved_var[tid()] mechanism could be adapted for this > pretty easily. The newer method using the kretprobe data pouch (bug #5916) is a > little tricker though, as it would need the types to be resolved a bit earlier > than we do now. Commit 8cc799a uses the "traditional" mechanism. We can try to add the kretprobe data pouch later.