RE: [Valgrind-developers] Developing Valgrind for Windows

[Jeremy F. <je...@go...>]

On Mon, 2004-03-01 at 15:36, KJK::Hyperion wrote:
> At 20.37 01/03/2004, Chris January wrote:
> >>My name is Rajesh and I am a student of Computer Sci in India. I want to 
> >>write a valgrind like utility for Windows. I know I sound silly but How 
> >>do I start? I am sorry if I am bothering u guys
> >Ithink your main work will be in re-writing vg_mylibc.c and vg_syscalls.c. 
> >vg_mylibc.c is ok to re-write but for vg_syscalls.c you need to know all 
> >the Windows syscalls, what parameters they take, etc.
> 
> I've been thinking about Valgrind on Windows for a long time, and here's 
> the major stumbling blocks I've found:
>   - absolutely, completely forget full virtualization, i.e. loading the 
> target program in the same process as Valgrind. kernel32.dll, user32.dll 
> and gdi32.dll can only be loaded *once per process* and *at their default 
> base address*, and it's very impractical to write Valgrind tools without 
> using Win32 functions. In detail:

Well, the thing which Valgrind ideally wants is two complete address
spaces: one for the client, and one for Valgrind.  The idea is that the
Valgrind should be able to control all the activity in the client
address space, control execution, inject generated code, etc.  We can't
get that with the Unix memory model, but maybe we can use the (otherwise
very painful) cross-address space features of Windows to get this
effect.

>      - kernel32.dll:
> [...]
>      - user32.dll, gdi32.dll:
>         - once per process for reasons similar to kernel32.dll
>         - at the default base address for reasons you really don't want to 
> know. It has to do with the fact that the windowing system was ported from 
> Windows 95, where not only user32.dll and gdi32.dll were actually loaded at 
> the same address in all processes, but they were also loaded in *shared memory*

Does this mean that if we translate this code into the instrumented code
cache, then things will care because the EIP isn't within the
kernel/user/gdi.dll?

Also, is this code running in Ring 3, or a privileged level?

> >I am willing to help you if you want.
> 
> count me in too, even if I think that nothing short of a full fork of 
> Valgrind will do 

I get that feeling too.

	J