> An "interposition device driver" is a fairly nice and easy
> thing to do here - e.g. one that invokes arbitrary added
> code when a system call is done. This code might be:
> in the kernel (gack); in a separate process, when it really
> amounts to "debug breakpoint on trap", where it will be
> too slow for many applications, but fast enough for some
> (such as the simulations I run); or perhaps using code/data
> memory added to the original program as transparently
> as possible.
>
> This is a special case of intercepting an arbitrary API.
> It is not as general. But it is more universally reliable
> than the binary editting approach.
Try a combined approach for speed: use debug-at-trap to find traps, then
try to install a patch at the invoking point to redirect to faster
debugless intercept code.
Of course, for new, not statically linked processes, LD_PRELOAD is almost
always better. Have a look at the Debian libtricks package, which uses
this to do all sorts of interesting stuff.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/