|
From: Robert W. <rj...@du...> - 2005-05-30 07:08:18
|
Hi all, I've put a new patch on my web site against the 2.4 tree: http://www.durables.org/~rjwalsh/software/valgrind 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: if delta %esp > some value, then assume a thread change 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. 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. Usage: * id =3D VALGRIND_STACK_NEW(start, end) registers the memory between start and end as a new stack and returns an id you can use for the other client requests described below. This doesn't allocate memory or anything - it just records that a particular memory range is a stack. * VALGRIND_STACK_DELETE(id) removes the stack association for stack "id". This doesn't free memory or anything - it just tells Valgrind that the piece of memory register earlier is no longer a stack. * VALGRIND_STACK_CHANGE(id, start, end) changes the stack "id" to a new start-end range. Useful if you're implementing stack growth in user-land, too. See the stack_changes.c file in corecheck/tests for an example. Some points: * This is currently only against the 2.4 tree. I'll port it to 3.0 in the next day or so. * I haven't measured this for performance impact yet. * I haven't tested VALGRIND_STACK_DELETE at all. * I've only tested VALGRIND_STACK_CHANGE for the default process stack, not for anything registered by the user. * Right now, it falls back to the old algorithm if the new one doesn't indicate a stack change. Probably this should just go away. * 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 have any thoughts, let me know. If there's going to be another 2.4 release, this might be useful to include. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |