On Wed, 24 Mar 2004, Scott Long wrote: > 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 ??? dogsbody and 2nd set of eyes.. julian(will be working with everyone I think) > > 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 >Received on Wed Mar 24 2004 - 10:44:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:48 UTC