This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]