|
From: Josef W. <Jos...@gm...> - 2005-01-21 09:28:28
|
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? > 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. > Comments? What have I forgotten? The calling convention is platform specific. Would it be detectable via configure tests? 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. As this is slow, it's not useful for general usage. Besides, I don't look at function arguments. But it would be really nice for tools to request for such a general wrapping mechanism; and the call stack clone should be able to always provide a good back trace. Josef > > J > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |