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

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

On Sat, 2004-01-17 at 18:30, Jeremy Fitzhardinge wrote:
> On Sat, 2004-01-17 at 01:50, Doug Rabson wrote:
> > On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote:
> > > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote:
> > > > This happens automatically in the FreeBSD kernel. When a thread blocks
> > > > in the kernel, an upcall to the userland thread scheduler happens and it
> > > > switches to the next runnable thread.
> > > 
> > > Ah, OK.  That sounds like an interesting thing to virtualize when we
> > > move to a threading model in which we expose virtual kernel interfaces
> > > rather than just pthreads.
> > 
> > That might be quite interesting indeed. It is possible that I might be
> > able to get the kernel threading authors involved if necessary though
> > since this stuff is fairly recent and is still being actively
> > maintained.
> 
> There's a tension between how we want to implement Valgrind and the
> kinds of client programs we want to support.  For Valgrind internally,
> we'd like to use the most portable code and interfaces, so pthreads
> rather than clone.  But we want to support all the clients, including
> those which use clone/rfork/upcalls directly. 
> 
> This means we need to do some things near the kernel interface to
> virtualize all those things.  For Linux with clone, signals are the only
> real problem, and only in 2.4.  Upcalls sound tricky; I don't know how
> they work (any docs pointers?), but it seems that if the kernel does an
> upcall, we need to intercept it, decide whether it is aimed at our
> libpthread or at the client, and do the appropriate demultiplexing.

There are some reasonable descriptions of the userland interface in the
kse(2) manpage. I imagine a few of the hairy details might still be
locked in the developer's heads but the manpage is a good place to get
started.

> 
> Given the large number of ways in which libpthread can be possibly
> implemented, it means that using libpthread for Valgrind itself doesn't
> necessarily give us any portability gains, because we still need to deal
> with the raw kernel interface on the client's behalf.  
> 
> The question is whether using libpthread is a net gain or loss of
> portability/complexity, and the answer isn't obviously clear to me.

Well I don't expect any real programs except a pthread implementation to
actually use these interfaces so perhaps its not a problem. On the other
hand we don't get to interpose our own libpthread for statically linked
programs. Regardless, I imagine the people implementing libpthread using
the KSE syscalls might find it useful to have a version of valgrind that
they can use to validate their work.

> 
> Anyway, all the more reason to do a FreeBSD port, from my perspective.

Right.

> 
> > There is a shared-address-space fork which I used to get proxylwp
> > working minimally on 4.x. I think the main problem with it as far as
> > pthreads goes might be the signal routing thing that linuxthreads has -
> > in fact there is a port of linuxthreads. The base system pthreads
> > implementation is purely user-space threading.
> 
> OK; what are rfork's signal semantics?  Is it simply that signals arrive
> at the process they're aimed at, with no shared signal state?  Does the
> existing signal router in vg_signals.c cope with this correctly?

I think thats right but I haven't delved too deeply into it. I think the
existing signal router should do the job - are there any valgrind test
cases that test that particular feature?