|
From: Jeff D. <jd...@ad...> - 2004-08-04 14:36:38
|
On Wed, Aug 04, 2004 at 08:52:19AM +0100, Tom Hughes wrote: > >> @@ -39,6 +40,10 @@ > >> # code which copies from baseBlock before the call, into > >> # m_state_static, and back afterwards. > >> > >> +.section .data > >> +save_ip: > >> + .long 0 > >> + > >> VG_(do_syscall): > >> # Save all the int registers of the real machines state on the > >> # simulators stack. > >> @@ -80,10 +85,27 @@ > >> movl VG_(m_state_static)+48, %esi > >> movl VG_(m_state_static)+52, %edi > >> > >> + cmpl $__NR_clone, %eax > >> + jne not_clone > >> + > >> + pushl %eax > >> + movl VG_(m_state_static)+60, %eax > >> + movl %eax, save_ip > >> + popl %eax > >> + > >> + int $0x80 > >> + > >> + cmpl $0, %eax > >> + jne parent_finish > >> + > >> + jmp *save_ip > >> + > >> +not_clone: > >> # esp now refers to the simulatees stack > >> # Do the actual system call > >> int $0x80 > > But how did you cope with the fact that valgrind doesn't protect it's > internal data structures in any way? You would have all sorts of > problems with two threads trying to access the same data. I think I was mistaken about this firing off another valgrind thread, for two reasons. I remember being concerned about whether the process data was still present in its normal, not running under valgrind, form. This would only be a problem if you were planning on running a non-valgrind thread in the same address space. Second, the patch above looks like it extracts the client IP from valigrind's state and branches to it. This would make the new thread a non-valgrind one. So, this being the case, there are no concerns about multi-threading V, just UML, which isn't your problem. Jeff |