Re: SF Bay area hackfest

On Wed, 24 Mar 2004, Scott Long wrote:

> On Wed, 24 Mar 2004, Daniel Eischen wrote:
> > On Tue, 23 Mar 2004, Scott Long wrote:
> >
> > > On Tue, 23 Mar 2004, Daniel Eischen wrote:
> > > >
> > > > For the KSE bits, we've already said a few times that we're
> > > > ready to go but are waiting for a toolchain upgrade that
> > > > supports TLS.
> > > >
> > > > > going to enforce.  I don't want 5.3 to go out with hap-hazard and/or
> > > > > unfinished TLS support.  SO let me start the list, and I'll let you and
> > > > > others add to it.  If we can't get through this step, then there is
> > > > > absolutely no way that we can expect to get this done for 5.3.  And for
> > > > > the record, I would really, really like to see this done for 5.3.
> > > >
> > > > I don't quite understand why you need commitments for a toolchain
> > > > upgrade.  From what I understand, TLS support can't happen without
> > > > it, and by deferring the toolchain update you prevent it from
> > > > getting done.  But I'll play along regardless...
> > >
> > > Operating without a plan or commitments leads us back to 2002 with KSE.
> > > If TLS needs a new binutils, then we need to figure out who is going to
> > > provide that.  If no one is going to provide it, then the rest is futile,
> > > no?
> >
> > Right, but the prerequisite for TLS is a new toolchain, not the
> > other way around; you don't need TLS support in non-toolchain
> > components to update the toolchain.  Once the toolchain supports
> > TLS, support for it can be added at any time, regardless of whether
> > or not it is before or after 5.3.  And yes, we (thread-guys) would
> > like to support it for 5.3 and have said so for quite some time.
> > We've already rearranged our per-{thread,KSE} storage to allow for
> > it.
> 
> Maybe something got misunderstood, then.  My intention was to create
> a list of tasks that need to be done in order to reach the final goal of
> having TLS work.  New binutils is one of those tasks.  I also wanted to
> stress that each task needs an owner, otherwise it won't get done.  Don't
> make me pull out MSProject and do this in a Ven diagram =-)
> 
> >
> > >
> > > What happens when the compiler, toolchain, etc, etc, are all updated to
> > > make TLS work, but the user libmaps C_R in?  Does stuff blow up?  I'm ok
> > > with C_R not explicitely supporting it so long as it doesn't create new
> > > failure cases.
> >
> > I guess stuff blows up, probably very similar to what already
> > happens when someone tries to use nvidia drivers/openGL with
> > libpthread or libthr.  But as far as I know, nothing we have
> > is currently built to use it (it probably can't be because
> > our released toolchain first needs to support it).
> >
> 
> This isn't terribly desirable since C_R is going to be the fallback thread
> package for 5.x.  Is there any way for C_R to detect when it's in a
> position to blow up and/or give an intelligent message to the user?

The linker could almost DEFINITLY do this
# myprog
ld.so: "You are tring to link libc_r to a program using TLS. Use
libpthread"
#

> 
> 
> Scott
>