|
From: Greg P. <gp...@us...> - 2004-12-16 12:33:16
|
I'm working on a port of Valgrind to Mac OS X, based on Paul Mackerras's Linux/PPC port. After about a week of bringup I have TextEdit.app running in simple recompilation mode - no optimization, no instrumentation, but mostly faithful simulation. So far, the bringup has been a rather destructive process. The scheduler and libpthreads were ripped out completely because they're inappropriate on Mac OS X. The dispatcher was rewritten because I didn't like the one that was there. Finally, large sections like the memory tracker and signal handling are disabled because I simply haven't gotten around to them yet. I started with Paul's "valgrind-2.3.0.CVS-ppc-tar.bz2", because it looked newest. Is there something else I should be working with? I have several PPC codegen fixes that I'll clean up in the next week or so, including a correction to stwux and similar; a correction to mfvrsave/mtvrsave; and a still-incomplete implementation of lswx/stswx. In a month or two I should have a better idea of where Valgrind's OS-specific assumptions are, and perhaps some ideas of how it could be layered to make it more portable. My porting procedure is still mostly "doesn't build? comment it out!" so I haven't really looked at most of the system yet. One area I have looked at is the threading model, which I understand has been a difficult point for Valgrind in the past. Mac OS X is based entirely on Mach threads; pthreads are entirely a userspace construction. This means Valgrind's "reimplement libpthread and a scheduler" is incomplete here, because many libraries manipulate the Mach layer directly, and I'd rather not reimplement the Mach API as well. My solution is as follows: Each thread in the inferior is a real Mach thread. Valgrind contains no scheduler and no reimplementation of the threading primitives. Instead, a single coarse-grained mutex is used to ensure that only one thread is executing in the Valgrind core at a time. If some thread is about to start a blocking syscall, Valgrind's syscall wrapper relinquishes the mutex, executes the syscall, and then blocks on the mutex before continuing execution. New threads block on the mutex before starting at their simulated entry point. Threads that have exhausted their basic block counter release the mutex and yield. The thread_suspend() trap throws in a few more curves, but nothing insurmountable. Almost everything else is handled automatically by the kernel's scheduler and threading primitives. So far, this mechanism works well, though I haven't thrown any heavily multithreaded tests at it yet. I haven't examined the possible interactions with signal handling, but signals are uncommon in Mac OS X applications so I'm willing to ignore them for now. The benefit is that I only need thin wrappers around a handful of Mach traps and some mutex management in the syscall handler. I used Purify on Solaris several years ago, and I've missed having that kind of power on the platforms I've used since then. About a year ago I looked at Valgrind, but the need for a new runtime and a PowerPC engine was too much for me. Now thanks to Paul I should have a good chance of pulling it together. -- Greg Parker gp...@us... gp...@se... |