|
From: Robert W. <rj...@du...> - 2005-06-02 06:33:41
|
Hi all, I've updated my stack changing patch (and rearranged my web page a little.) http://www.durables.org/~rjwalsh/software/valgrind/ New in this version: * Added a version of the patch for Valgrind 3.0. * Made some minor modifications to make the 2.4 version look more like the resulting 3.0 version. * Incorporated some feedback from Nick about names. The user requests are now called VALGRIND_STACK_REGISTER and VALGRIND_STACK_DEREGISTER (instead of VALGRIND_STACK_NEW and VALGRIND_STACK_DELETE.) Still to do: * Document usage. * Measure performance impact. * Write tests for VALGRIND_STACK_DELETE and VALGRIND_STACK_CHANGE. * It could probably be made a bit more efficient by using an interval skip-list to store the registered stack data instead of a simple linked-list. After I see the performance impact, I'll decide about this. If you missed what this is all about, here's what I said in my last email: The patch allows user-land thread packages (e.g. coroutines) to deal with stack changes gracefully. Currently, Valgrind notices when %esp changes and uses a heuristic to figure out if that possibly means a thread change, or just that something large was pushed onto the stack. It often gets it wrong, since the heuristic is basically: =20 if delta %esp > some value, then assume a thread change =20 The problem is, it's hard to know what a good "some value" is since it depends a lot of how your program is written. =20 The change I've made allows you to register a memory range as a stack with Valgrind. Valgrind spots when %esp changes and checks if it's changed to a different registered stack. If it has, then it assumes a thread change. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |