Does -CURRENT's gcc generate ___tls_get_addr under any

[John Merryweather Cooper]

On Sat, Jun 26, 2004 at 04:39:33PM -0700, Julian Elischer wrote:
> 
> 
> On Sat, 26 Jun 2004, David O'Brien wrote:
> 
> > On Fri, Jun 25, 2004 at 02:15:04PM -0700, Julian Elischer wrote:
> > > On Fri, 25 Jun 2004, Joe Marcus Clarke wrote:
> > > > On Fri, 2004-06-25 at 16:44, John Merryweather Cooper wrote:
> > > > > I'm working on porting (and getting fully working) lang/mono
> > > > > version 0.96, and I'm having a problem.  In one of my object
> > > > > files--mini.lo--I'm getting an extern reference to
> > > > > ___tls_get_addr.  I've been over the source code in mini.c
> > ...
> > > TLS is coming.. it's just not here yet..
> > 
> > By whom?  I've done the part I committed to. Yet I've heard nothing else
> > about TLS in the two weeks after it was possible to start work on the
> > next part.
> 
> Doug Rabson has partly working TLS in p4 and last I heard was awaiting 
> some comments from the nvidia people who would be our first users of
> TLS.
> 
> 
> 
> >  
> > -- 
> > -- David  (obrien at FreeBSD.org)
> > 
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 

Well, I've managed to figure out my ___tls_get_addr problem.  It appears to
act as a result of those features of TLS currently implemented into the
compiler and a configure test for the "new pthread library" or nptl for
short.  The configure script detects the ability to use __thread to declare
thread-local variables and determines from this that nptl should be used.

Of course, we're not ready for nptl, so --with-nptl=no needs to be set
to override what the tests determine.

jmc