Re: [DynInst_API:] Proposal: Add System Call Events to ProcControlAPI

[David Smith <dsmith@xxxxxxxxxx>]

On 05/23/2013 01:47 PM, Bill Williams wrote:
> On 05/23/2013 11:50 AM, David Smith wrote:
>> On 05/20/2013 09:53 AM, Emily Jacobson wrote:
>>> Hi all,
>>
>> Sorry for taking so long to respond to this.
>>
>>> We’re proposing adding system call callbacks to ProcControlAPI. After
>>> internal discussion, we're sending out this proposal for wider feedback.
>>> What follows is an overview of this feature, as well as the proposed
>>> ProcControlAPI interface. For this feature to be exposed in the
>>> DyninstAPI interface, it must first be exposed via ProcControlAPI. We
>>> expect the DyninstAPI interface will closely mirror this.
>>
>> I've never used the ProcControlAPI interface, but I'll just assume the
>> DyninstAPI will look the same and go ahead.
>>
>> ... stuff deleted ...
>>
>>> *Proposed Interface:*
>>>
>>>
>>> A new Event child class: EventSyscall.  An EventSyscall is triggered
>>> when a thread, which was put in syscall-monitoring mode by
>>> Thread::setSyscallMode, enters or exists a system call. The Thread will
>>> remain in syscall-monitoring mode after completion of this event
>>> (presuming it has not been explicitly disabled by
>>> Thread::setSyscallMode). An EventSyscall may be associated with an
>>> EventType of pre-syscall (system call entry) or post-syscall (system
>>> call exit).
>>
>> So, Thread::setSyscallMode turns on/off syscall monitoring. When on,
>> EventSyscall events get seen.
>>
>> In my head when thinking about this, I would have figured syscall events
>> would follow more of the existing event handling mechanisms, like
>> registerThreadEventCallback(). But, perhaps this is the difference
>> between the ProcControlAPI and DyninstAPI?
>>
> Sort of, yes. The ProcControl method for registering callbacks is to
> register them for particular events and have each callback take an
> Event*. Dyninst then wraps this in this (older) style of one interface
> method per type of callback. So at the ProcControl level you'd register
> a callback handler for EventSyscall, but at the Dyninst level you'd do
> something like registerPreSyscallCallback/registerPostSyscallCallback.
> 
> However, tracing syscalls is expensive and we only want to enable it for
> the processes/threads that a user cares about. So, in keeping with our
> existing model of "all user callbacks are global", you'd register the
> callback and orthogonally enable/disable the syscall events being
> generated. We've internally discussed the pros and cons of allowing user
> callbacks to be registered at a finer scope, which would allow us to
> automatically enable/disable syscall tracing based on what a user tells
> us they need. Right now that's a large change that wouldn't necessarily
> provide a large benefit; thoughts?

Systemtap syscall probes are done at the process level. So, we wouldn't
register them at a finer scope.

Oh, one more thing. Systemtap probes always run in the context or the
probed process (i.e. the mutatee). So, we'd be using oneTimeCode() to
call the probe function in the mutatee when a syscall probe hits, making
an expensive operation even more expensive. If there was a way around
that it would be useful (for systemtap anyway). But, perhaps our use
case is too specialized.

> Also: preferences on whether you'd get handed EventSyscalls or
> MachSyscalls plus some other data from a BPatch-level callback?

As long as the data can be accessed, I'm flexible.

-- 
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)