Re: [Valgrind-developers] ValGrind on Solaris ?

[KJK::Hyperion <no...@li...>]

At 10.19 27/11/2003, Nicholas Nethercote wrote:

Apropos of this:

>A Solaris port has been requested almost as frequently as a Windows port.

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, I have a question for you: how does (or 
does) Valgrind cope with modifications on the current process performed by 
other processes? 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. Such kind of 
interactions is a widely used form of inter-process communication 
(especially the exchange of object handles, which can also overwrite small 
areas of memory), and it makes the job of programs like Valgrind much 
harder without explicit support from the kernel. Also consider that 
kernel-mode code is free to write to any memory location, and some drivers 
may even create permanent kernel-mode threads in any process, so all of 
Valgrind's fancy memory checking and tracking can be quite pointless in 
several cases

This is the only real difficulty on Windows, as system calls don't require 
to be run on any specific stack (in fact, the Win32 ExitThread function 
switches to a fixed stack allocated in the per-thread data segment before 
freeing the thread's real stack), all kernel-user transitions happen at 
well-known entry points (and this makes for easy hooking of exceptions, 
callbacks and APCs) and an APC (roughly equivalent to a signal), handled by 
a well-known function, is posted to every thread as soon as it's created, 
so hooking process and thread creation, and even running before any kind of 
initialization code, is a piece of cake

>But a port would be difficult to a non-open source OS, because Valgrind 
>does lots of low-level OS stuff.

Windows received a lot of attention from many skilled people, and Microsoft 
has let a lot of information to leak, over time. As an effect, we currently 
know a whole lot about its internals, including system calls (nearly all of 
them are officially undocumented), internal kernel features, routines and 
structures, and even the build environment used at the Microsoft labs. 
ReactOS (<http://www.reactos.com/>) is probably the greatest result 
achieved through this knowledge: it's an open source operating system 
aiming at (and slowly reaching) 100% binary compatibility with Windows. So 
this is not going to be the problem with Windows