mudflap vs. varargs

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


Testing mudflap on bigger programs has turned up an interesting
case where pure tree-level instrumentation is insufficient: varargs
functions.  The current code results in violations at each va_arg()
call within the varargs callee, since a hidden pointer into the stack
frame is being dereferenced.

The basic problem is that the anonymous arguments are not registered with
libmudflap runtime.  If we wanted to protect each individual argument,
the runtime would need to be told the CALL_EXPR run-time addresses on
the stack, which is kind of hard since the normal registration itself
consists of a function call.

So, I'm thinking of a few options:

- avoiding instrumenting the va_arg construct altogether, thus not
  protecting vararg parameter passing

- passing an extra sentinel parameter from vararg callers; instrument
  the callee to look for that sentinel and register the entire
  argument region on the call frame

- passing call argument metadata in a global or thread-local
  variable for slower but more reliable extraction and registration
  in the varargs callee

Any suggestions, ideas?


- FChE