Re: newbie question: tracing userspace call/return sequences

[Christian Convey <christian.convey@gmail.com>]

On Fri, Jan 6, 2017 at 5:16 AM, Milian Wolff <milian.wolff@kdab.com> wrote:
...
> There is a catch-all handler:
>
> *trace_unhandled*, if defined, is called after for any event that
>  doesn't have a handler explicitly defined for it.  The standard set
>  of common arguments are passed into it:
>
> ----
> def trace_unhandled(event_name, context, common_cpu, common_secs,
>         common_nsecs, common_pid, common_comm):
>     pass
> ----
>
> Maybe you can use that one instead? I'd still be interested to know whether
> you can get all required information. If not, extending the API is doable.

Hi Milian,

Thanks for the idea - I tried it out.  My Python script was a bit ugly
/ hackish, but it did allow me to trace basic call/return information.

With your approach, it was also easy to trace the return-value of each
function call: I modified my return-probe definition to be "*:%return
$retval".  After that, the "trace_unhandled" function can access the
return value via "event_fields_dict['arg1']".

There are two more improvements I'd like to make, but they're less important:

(1) For each function being traced, I'd like to report the values of
all of its parameters.  (SystemTap makes this easy.)  Unfortunately,
`perf probe`'s probe-argument syntax seems to require that I know the
name of every function-parameter I want to probe.  So I may end up
having to write a script that parses either (a) the target program's
DWARF info, or (b) the output of `perf probe --vars`.

(2) I want the tracing to be robust even if the target program
dynamically links to `.so` files that I didn't anticipate when
creating the probes.  I haven't found any documentation regarding how
gracefully perf, SystemTap, etc. handle that situation.  I'm not sure
how I'd solve this problem.  Perhaps hooking `dlopen` is an option.

- Christian