|
From: Nicholas N. <nj...@ca...> - 2004-08-05 21:44:00
|
On Thu, 5 Aug 2004, Andy Bakun wrote: > Just throwing out an idea here -- but how possible would it be to run a > tool in a different process and have valgrind communicate with the > tool's process over IPC? Then the working set of valgrinding something > is the normal size of the process + overhead of valgrind itself, rather > than process + valgrind + tool. The tool would have a full address > space at its disposal. There is speed to consider, this would most > likely be slower than the suggested 1-2% slowdown from using -fPIC, but > you'd at least be able to valgrind larger processes then. If you used > sockets between valgrind and the tool, you could even run the tool on a > different machine, perhaps one with more RAM. You might even be able to > run multiple tools at the same time this way. This is not necessarily a > good idea though, most likely a lot of work to further abstract the > memory accesses through the tool to allow non-direct access (I have not > examined the code at this level of detail). Every memory access would have to pass through a socket. And maybe every register access, depends how you structure it. I don't know much about IPC and sockets, but I imagine this would fatally reduce speed. I think the current approach can be tweaked so that things aren't so problematic, eg. by having an option that makes memory layout less rigid. N |