Re: TLS bug?

On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote:
> On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote:
> > Using bonnie++ I can't reproduce this (didn't try mysql) but I have
> 
> I seem to have good luck reproducing it with "-r 5 -s 10 -x 10" by about the
> third iteration.

Ok, with these parameters I can reproduce it.

> 
> > some TLS fixes for libthr I forgot about but could be relevant here
> > (most actually date back to 2008 when the base binutils didn't support
> > GNUTLS for sparc64 so I couldn't test them easily). Could you please
> > give a libthr build with the following patch a try?
> > http://people.freebsd.org/~marius/libthr_sparc64.diff
> 
> Concurrent runs both with and without those diffs still asserted.
> Interestingly, libc's .tbss section, even after the assertion, is still full
> of zeros, so it looks like something stranger than a wild-write back to
> .tbss.  I'll go diving through the tls allocation code again when I get a
> minute.
> 

In combination with the below patch bonnie++ survived 100 iterations
here. I'm not sure what this means though as I don't have much knowledge
about TLS, I merely implemented the necessary relocations. Could be
that malloc() actually requires the initial exec model for variant II.
Unfortunately, it's not documented why it was added for x86.
Jason, can you shed some light on this?

Marius

Index: malloc.c
===================================================================
--- malloc.c	(revision 219535)
+++ malloc.c	(working copy)
_at__at_ -234,7 +234,7 _at__at_
 #ifdef __sparc64__
 #  define LG_QUANTUM		4
 #  define LG_SIZEOF_PTR		3
-#  define TLS_MODEL		/* default */
+#  define TLS_MODEL		__attribute__((tls_model("initial-exec")))
 #endif
 #ifdef __amd64__
 #  define LG_QUANTUM		4