Re: SF Bay area hackfest

Daniel Eischen wrote:
> On Wed, 24 Mar 2004, Scott Long wrote:
> 
> 
>>On Wed, 24 Mar 2004, Daniel Eischen wrote:
>>
>>>>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?
> 
> 
> It's probably easier just to add TLS support to libc_r if it's
> highly desirable.
> 

Note that it's highly desirable, but not the highest priority.

So our table is now:


  Task                                 Owner

  Import new GCC                       Alexander Kabaev
  Import new binutils                  ???
  Modify loader (image activator?)
   to understand TLS                   ???
  Modify KSE to understand TLS         Dan Eischen/David Xu
  Modify dynamic linker for TLS        Doug Rabson
  Modify THR to understand TLS         ???
  Modify C_R to understand TLS         ???

It looks like we are gaining critical mass on this.  C_R and THR are
less important, and I'd even be willing to take a look at them myself.
David, can you help with the binutils?  It sounds like there might be
some issues with libbfd if binutils is upgraded but gdb is not.  Can we
discuss the options here?

Thanks,

Scott