RE: [Valgrind-developers] Developing Valgrind for Windows

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

Quoting "KJK::Hyperion" <no...@li...>:

> At 02.36 08/03/2004, Jeremy Fitzhardinge wrote:
> >Two linear address spaces (ie, two separate unix processes) would allow
> 
> >the client to have full run of one whole address space, but there's no
> 
> >clear way in which generated code could have efficient access to both
> 
> >address spaces.
> 
> couldn't the memory for the data be shared between the two processes?
> and 
> offsets used in place of pointers?

Well, the data is the big thing, so you'd stll have the problem of fitting 
everything into the one adderss space.  memcheck uses 9 bits of shadow for every 
8 bits of client memory, so if they're both in the same address space, you're 
always going to be able to use less than half the avaliable adderss space for 
your program.

> but to me it looks like it isn't real multithreading. From the papers
> I've 
> read, it looks like it's emulated. Would it be problematic to make
> Valgrind 
> truly multithreaded?

That would be very hard work, since every instruction could potentially be 
concurrently modifying some structure which is being used by another thread.  It 
is really multithreaded as far as the client is concerned; the main problem is 
that it will only ever use 1 CPU on an SMP system.

> >I guess this would be an elaboration of the games we play currently
> with 
> >signals?
> 
> yes, except a lot easier :-) 

Yes, I think I can see how they can be handled.

> mov eax, <system call number>
> mov edx, <very high, fixed address>
> call edx
> retn <size of parameters>
> 
> The "very high" is an unbelievable 0x7FFE0300, straight in the middle of

Hm, that isn't all that high.  Does that mean a process has less than 2G of 
available address space under XP?

> It looks like that the actual system call thunking code (sysenter, it
> turns 
> out) is generated by the kernel at boot time, and written there to
> shield 
> user-mode code from CPU subtleties.

Linux does the same thing these days; the syscall entrypoint is at 0xffffd000 or 
so, and it contains whatever is the most efficient way of doing a syscall on this 
CPU.

	J