|
From: Tom H. <th...@cy...> - 2004-12-16 13:36:33
|
In message <200...@ka...>
Greg Parker <gp...@us...> wrote:
> 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.
Sounds excellent.
> 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.
As far as PPC goes that is probably the newest, but I'm not sure
what date the CVS tree it is against is for.
> 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.
Nicholas Nethercote has done a large amount of work on factoring
out OS and processor specific code - look at the current CVS head
to see where the layering is going on that front. Nick is away at
the moment though.
There is also work ongoing on a new model for the virtual CPU to
better support additional processors - that work isn't in CVS 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.
I for one would dearly love to get rid of the current pthread
replacement model - it is a pain in the rear. I think there is
a pretty good consensus here that it should go as well.
One problem is that we still need to be able to track certain
events for things like helgrind that want to know when mutexes
are locked and unlocked.
> 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.
That's more or less the sort of thing we were talking about although
that method of handling system calls hadn't occurred to me. On a
modern linux we can use a futex for the master lock which should be
fairly efficient.
We did actually have a solution along those lines working at one point
for wine although that was based around using sigsuspend when a thread
wanted to relinquish control and sending a signal to the next thread
to wake it up just before it suspended itself.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|