This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: treatment of inline functions
- From: Roland McGrath <roland at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Sun, 4 Feb 2007 12:48:36 -0800 (PST)
- Subject: Re: treatment of inline functions
> - The way in which systemtap resolves function/inline probes has changed:
> .function(...) - now refers to all functions, inlined or not
> .inline(...) - is deprecated, use instead:
> .function(...).inline - filters function() to only inlined instances
> .function(...).call - filters function() to only non-inlined instances
I take "inlined instance" to be the technical term as used in DWARF,
i.e. the concrete instantiation of an abstract inline function definition.
But you should make it more clear to all readers what that means.
I wonder if anyone cares about the other axis of selection, which is
"declared as inline" (DW_INL_declared_inlined or
DW_INL_declared_not_inlined), a source-level distinction, rather than
"actually inlined" (DW_INL_declared_not_inlined or DW_INL_inlined), a
low-level detail chosen by compiler optimization.
Another feature that comes to mind is:
.function(...).inline.caller(...)
after selecting concrete inlined instances, you can filter on their
call_file/call_line and/or haspc. For inlines from header files, this might
be nice, i.e. list_add when inlined inside function foobar.
Thanks,
Roland