|
From: Jeremy F. <je...@go...> - 2005-01-22 17:17:18
|
On Fri, 2005-01-21 at 02:00 +0100, Josef Weidendorfer wrote: > On Wednesday 19 January 2005 22:29, Jeremy Fitzhardinge wrote: > > [...] > > OK, so that's normal call-return: how to deal with longjmp/exceptions? > > Well, we could just ignore it. If you call a wrapped function, and it > > longjmps back, it means that the "before" function is called but not the > > "after", and the cookie store fills up with junk. That's not optimal. > > With longjmp/exceptions, 2 cookies could be created with the same > TID+ESP+RETADDR (same call chain after a exception). Is this a problem? Well, after the longjmp, the first instance has been invalidated after ESP changes, so should "disappear". If there is a second occurance, the first should just be replaced. > > 3. Generate the call to wrap_after_func, just by overwriting the > > standard preamble. > > What happens if the TC is flushed before the function returns? A retranslation > would have to know about changing the preamble. That would be the common case - the first time a BB after a call is generally run is when that call returns. So there would need to be a structure to let the codegen know to generate the call to wrap_after_func in this case. > The calling convention is platform specific. Would it be detectable via > configure tests? Well, yes, it is platform-specific, like all the other CPU-specific stuff. So I don't think this is a special case. > General function wrapping is expensive. In my tool, I manage my own call stack > for this, and insert a callback at start of every BB which syncs/unwinds the > call stack according to %ESP. This doesn't need any temporary modification of > instrumented code, and works for longjump/execptions in a natural way. Wrapping every function is going to be expensive, yes. My design goal was for a mechanism which is efficient when applied to a relatively small number of functions. J |