Bug 23761 - generalized @entry
Summary: generalized @entry
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: tapsets (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Jafeer Uddin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-11 18:46 UTC by Frank Ch. Eigler
Modified: 2018-11-07 15:30 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2018-10-11 18:46:03 UTC
With the arrival of non-[uk]retprobe mechanisms to trap return events (e.g., tp_syscall.*.return), the traditional @entry(expression) trick is no longer directly workable.  This is because there is no mechanically-obvious entry probe to collect the expression, and @entry($var) may need $var that are not available at all in that form.

So we need to generalize this a bit.

One way is to introduce some macros that explicitly implement the @entry() machinations behind the scenes:

- one macro to 'probe entry point & save variables'
- and one macro to 'probe exit point & expose saved variables'

used something like

probe syscall.* { @save(myargstr,argstr) }

probe syscall.*.return { 
    @restore(myargstr)
    log(myargstr)
}

which would expand to code that manages a myargstr global array, tid()-indexed.
Comment 1 Jafeer Uddin 2018-11-07 15:30:43 UTC
Fixed in commit 4ee1ae49ae. Decided to define 8 tid()-indexed global variables (accessed using @this1, ..., @this8 macros) that can be used to save in entry probes and restore in return probes. For example:

probe syscall.* { @this1 = argstr }

probe syscall.*.return {
    argstr = @this1
    log(argstr)
}