Re: [DynInst_API:] urgent RFC: dyninst/proccontrol callbacks

[Josh Stone <jistone@xxxxxxxxxx>]

On 06/24/2016 10:10 AM, Bill Williams wrote:
> Folks--
> 
> As any of you who've worked on (or with) proccontrol know, it's a 
> complex beast. (If you don't know, Bart and I will be happy to tell war 
> stories over beer...) One of the particular areas of complexity is 
> stopping a process in order to deliver a user-level callback; another is 
> deciding what operations are legal from within a callback (and what a 
> user can request post-callback).
> 
> We've discovered that LWP exit callbacks being allowed to stop an entire 
> process are a bad idea (and near-impossible to implement correctly on 
> linux in the face of signals): 
> https://github.com/dyninst/dyninst/issues/100. As a consequence, we're 
> looking into whether and how we can redesign our callback mechanisms, 
> both in Dyninst and in Proccontrol, to be more restrictive--in 
> particular, to disallow process-level stops as return values.
> 
> Urgent questions follow; negative answers are at least as valuable as 
> positive ones.
> 

Answers here are for systemtap's --runtime=dyninst (stapdyn).

> 1) Do you use ProcControl callbacks for thread/process events?

No.

> 2) If so, which ones, and for what purpose(s)?

N/A

> 3) Do you use BPatch callbacks for thread/process events?

Yes.

> 4) If so, which ones and for what purpose(s)?

We always register for fork, exec, and dynlibrary callbacks, so we can
place instrumentation in new processes and dlopened libraries.

If our user's script calls for it, then we'll also register for exit and
thread create/destroy events.  We don't do anything in the mutatee at
all for process exits, just run the user's handler locally.  On the
thread events we do try to run in the mutatee with
BPatch_thread::oneTimeCode().  This is imperfect...

> 5) If you don't use callbacks but are emulating their functionality 
> (e.g. with breakpoints or instrumentation), can you describe your use 
> case for the benefit of folks who are currently using callbacks?

We don't do this, although stap scripts are flexible enough with
instrumentation that our users would be free to do this on their own.

We might consider it though, to give a little better experience with
thread and process exits, especially being able to run a bit of code
beforehand.  I know that wouldn't work for exits by signal though.

> Any/all feedback is greatly appreciated; while I doubt that these 
> changes will make it into 9.2, redesigning these interfaces and our 
> internal client code that relies on them is going to take some thought 
> and some testing, and I want to ensure that we can get the bug I've 
> linked above fixed for a 9.3 release.
> 
> Thanks for your time.
> 
> --bw
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>