At 13.10 29/11/2003, Nicholas Nethercote wrote:
>>I subscribed this mailing list precisely to ask about a Windows port, but
>>gave up temporarily when I read on the website about Valgrind's non
>>existent support for multi-threaded processes
>>Assuming this isn't true anymore,
>Valgrind has supported multi-threaded processes for over a year now, maybe
>even 18 months.
this text in the technical overview is very misleading, then:
>Doing a good job of thread support strikes me as almost a research-level
>problem. The central issues are how to do fast cheap locking of the
>VG_(primary_map) structure, whether or not accesses to the individual
>secondary maps need locking, what race-condition issues result, and
>whether the already-nasty mess that is the signal simulator needs further
>I realise that threads are the most-frequently-requested feature, and I am
>thinking about it all. If you have guru-level understanding of fast mutual
>exclusion mechanisms and race conditions, I would be interested in hearing
>>on Windows any process can modify any other process, given sufficient
>>access to the target process object and related thread objects, and such
>>modifications include allocating pages virtual memory, mapping pages of
>>shared memory, writing ranges of memory, duplicating object handles, even
>>altering the threads' contexts and LDTs.
>Urgh... that sounds awful, like it would interact really badly with the
>way Valgrind works.
well, not that this kind of things happens normally. I think most
inter-process memory writes happen either in a controlled way through the
RPC system calls, and they're easily trackable, or through shared memory,
something Valgrind wouldn't have much control on anyway. But you confirmed
one of my fears. I guess I can lower the priority of a Valgrind port on my
On a lighter note, Windows is very liberal about features and practices
that would make any purist OS developer crazy. System calls, for example,
use pointers passed by user-mode programs directly (after checking that the
whole range is contained in user-mode memory, of course), with no explicit
checking: access violations (segmentation faults) are handled in a manner
similar to C++ exceptions, by unwinding the stack frames until the
exception handler and setting the return value to the exception code. This
isn't an implementation accident, but an explicit design feature: error
codes and exception codes even share the same namespace (e.g. in UNIX you
have EFAULT and SIGSEGV, while in Windows NT STATUS_ACCESS_VIOLATION covers
both). You may also be surprised and outraged to discover that "statically
linked" programs are impossible: as soon as a process is created, a special
DLL (ntdll.dll) is injected into it, that contains the executable loader,
the system call thunks and some runtime libraries (like the heap manager).
Another cause of surprise and frustration is the area of memory shared
between the kernel and every user-mode process: not a bad idea in itself
(it lets you access the internal tick counter directly, discover the kernel
version, and more), if only it wasn't loaded at a fixed address. In
general, kernel-user interactions are often unorthodox and pretty extreme.
The windowing system, for example, having been ported from a shared-memory
system (think Windows 3.1), lets any client access its internal data
structures (read-only, of course) - GDI handles, if any of you is familiar
with them, aren't handles at all, but indexes in a huge array of GDI
objects; same for window handles. Not to take up precious kernel virtual
memory, the windowing system maps its shared data in write mode in a
special process, and switches to its virtual address space whenever it
needs to make any modification. And I think I already mentioned the
kernel-mode threads you're free to create in any process
>>This is the only real difficulty on Windows
>Er, I think that might be understating things a bit. For example, I
>imagine it would be much easier to port to a *nix OS than to Windows.
hm, I don't know. How does Valgrind's memory checking work? does it keep a
cache of the memory status somewhere? and the real memory of the process is
kept in synch with the emulated memory?
>I had a look at that site. AFAICT, they started in 1997, and can now run
>a few programs on NT 4.0.
we can run a few Windows NT 4 *drivers*, please :-)
>Sure, it is possible to find out about Windows internals, but a port to an
>open-source OS would be *much* easier.
I think that's not the major problem here. Let's say I am providing a
precedent you can point people at (is this mailing list archived somewhere?)