|
From: Jeremy F. <je...@go...> - 2004-01-15 18:08:35
|
On Thu, 2004-01-15 at 02:27, Doug Rabson wrote: > The other thing I've been thinking about recently is that now we can use > library routines fairly safely, why not re-implement vg_proxylwp using > pthreads? That would make the only non-portable part the actual syscall > delivery. I might actually try that. Yes, that's on my list of things to do. I'm a bit worried by a few things; since the proxylwp does direct syscalls (invokes int 0x80 directly), the threads implementation has to be able to cope with that (which probably means 1:1 app thread:kernel thread ratio). The direct syscalls are still required so it can maintain the signal/restart state machine properly. On the plus size, it would allow me to drop the use of pipes as a thread communication/synchronisation mechanism, and use pthreads operations instead, which will be more efficient with any luck. Hm. There's still one hole in allowing unfettered use of system libraries - we need to make sure that any FDs opened are pushed into Valgrind's range. > I've been thinking about that too. One thing to bear in mind before you > fix on a structure is the problem of amd64 and ia64. For amd64, the > instruction set is almost identical with the main difference being a few > extra prefixes and wider registers. A decompiler for amd64 should share > almost all the i386 code. > > To a much lesser extent, the i386 decompiler would be useful on ia64 too > since its possible to switch between ia64 and ia32 instruction sets at > will. In practice, perhaps this doesn't happen though. I know ia64 has the ability to switch on a jump, but I was hoping that in practice the change only really happened at execve time (like amd64's transitions). If we were to support ia64 dynamic instruction set switching, it would complicate things quite a bit, since we'd have to have two complete implementations of the dynamic translator (not to mention the cost of switching between the client's instruction set and Valgrind's). J |