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

[Jeff Hollingsworth <hollings@xxxxxxxxxx>]

On 5/24/2013 3:49 AM, Barton Miller wrote:

On 5/23/2013 4:57 PM, Emily Jacobson wrote:

On Thu, May 23, 2013 at 4:40 PM, David Smith <dsmith@xxxxxxxxxx> wrote:

> In our initial implementation, we are not planning on providing argument

> access (raw values or otherwise), partly due to the complexities you
> mention. Currently, users may use raw memory and register access
> (available via existing API calls) to read system call arguments.
> Software built on top of Dyninst would be responsible for understanding
> system call semantics. If Dyninst were to provide argument access in the
> future, we would like to represent syscall arguments in the same form as
> our existing function parameter access (i.e., BPatch_paramExpr).

Hmm. Wouldn't you need to keep up with all syscalls yourself here to
provide typed parameter access? There isn't any dwarf info here, right?
That's a big job, especially considering arch-specific syscalls and
32-bit-on-64-bit executables. If you haven't already, take a look at the
source to strace.

Yes, if Dyninst were to provide argument access, we would need to support that level of semantic information; I definitely agree that this would be a big task. That added complexity is a large part of the reason argument access is a hypothetical future feature and not intended to be part of this initial interface and implementation.

A couple of things.  First, this functionality probably belongs in a "value added" library that sits on top of Dyninst or its toolkits.  It doesn't need to go inside.

Second, the semantics of the argument types should be defined by the syscall number.  It's a bit of work, but mostly one-time work to define a table of argument number and types for each syscall.  And there would be table version for each platform version of the library.  An interesting question is whether there is a DWARF-ful version of libc so that we could build this table automatically?  (Or could we just trigger our own build of libc?)

Or perhaps we can auto-generate it from the kernel source?  That would allow us (for Linux)  to auto-pull kernels from kernel.org and generate the configuration files.

Jeff