[Valgrind-developers] Re: source tree rearrangement, part 2

[Doug R. <df...@nl...>]

On Thu, 2004-01-15 at 18:08, Jeremy Fitzhardinge wrote:
> 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.

I put something together today (attached). I also had to tweak
vg_mylibc.c somewhat since my pthreads library wanted to override
sigprocmask, sigaction etc. I've attached the result for your amusement.

> 
> 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.

I left the pipes alone in the interests of simplicity.

> 
> 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 didn't think of that. I don't think that any of the FreeBSD pthreads
implementations has any internal file descriptors. I'm not sure about
NPTL/linuxthreads.

> 
> > 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).

I think that it probably never happens in practice. Just implementing an
ia64 jit at all will be enough work without worrying about ia32
switching.