|
From: Julian S. <js...@ac...> - 2005-01-20 00:00:19
|
> I think, however, that it is a > vast improvement over the outright functional bugs (and maintenance > problems) which vg_libpthread had. And certainly better than not > reporting anything as we do now. I agree. We should make this work if we can. > We could take advantage of the codegen. If we're generating code for > the first basic block of a wrapped function, we could generate in the > preamble: > call wrap_before_func > wrap_before_func would then be able to inspect %ESP and get both the > args and the return address. The value of TID+ESP+RETADDR will give us > a unique cookie key to match the call to the return. Who writes wrap_before_func? That has to understand the baseblock layout and also the calling conventions to extract esp and retaddr, and so is going to be machine specific. > Inserting the call to wrap_after_func at R is very easy; it doesn't even > require regenerating the BB. Currently, the first 16 bytes of each BB > is a preamble which is solely concerned with decrementing and testing > VG_(dispatch_ctr); we can easily do this in wrap_after_func, so we can > just patch over the preamble with the call to wrap_after_func (and nop > out the rest). That will change drastically .. the new JIT (1) translates multiple BBs at a time, and (2) actually doesn't do translation chaining as I could not think of a clean way to do this portably. ----------- The proposal leaves me with a nasty feeling that it will introduce all sorts of complex inter-component dependencies and generally be a maintenance and portability problem later. ----------- I would prefer a solution which didn't involve so much magic in the JIT. Why do we need general function wrapping? Currently all we care about is intercepting libpthread calls. I would prefer to write, in C, a libpthread stub library, and use the existing intercept mechanism to route all calls there. The stub library emits events -- using the client request mechanism -- to those who want to know, and calls onwards to the real pthread functions (my hands wave here). No need to mess with calling conventions, guest state layout or magic run-time code modification. ------------ The cookie idea seems like the kernel of something useful -- that is, a clean statement of the semantics of function wrapping in the presence of recursion, threads, and functions which don't necessarily return. J |