[Mesa-dev] [PATCH 1/4] dispatch: Use general-dynamic TLS model rather than initial-exec.

[Christopher James Halse Rogers]

On Wed, 2011-03-30 at 16:21 -0400, Jerome Glisse wrote:
> On Thu, Mar 24, 2011 at 2:32 AM, Christopher James Halse Rogers
> <christopher.halse.rogers at canonical.com> wrote:
> > On Thu, 2011-03-24 at 16:07 +1100, Christopher James Halse Rogers wrote:
> >> On Wed, 2011-03-23 at 17:48 -0700, Eric Anholt wrote:
> >> > On Thu, 24 Mar 2011 10:33:36 +1100, christopher.halse.rogers at canonical.com wrote:
> >> > > From: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com>
> >> > >
> >> > > The initial-exec static TLS model is inappropriate for libraries
> >> > > that might be dynamically loaded.  Since libGL is dynamically loaded
> >> > > by any number of projects mesa must instead use the general-dynamic
> >> > > TLS model.
> >> > >
> >> > > This has apparently always been broken for projects dynamically loading
> >> > > libGL and libstdc++, but now that libGL links to libstdc++ it's much
> >> > > more visible.
> >> > >
> >> > > cf: Launchpad bug: https://bugs.launchpad.net/bugs/259219
> >> > > First part of fix for https://bugs.freedesktop.org/show_bug.cgi?id=35268
> >> >
> >> > Looks like someone bisecting through and hitting the first commit would
> >> > get a broken build.  I would think squash 2/4 and 3/4 and move the
> >> > _glapi_tls_Dispatch change to that new commit.  I didn't receive patch
> >> > 4/4.
> >>
> >> Ah, I see I've got a bounce for 4/4 due to the size; it's regenerating
> >> the assembly files.  I'll clean this up and send the regeneration patch
> >> separately.
> >
> > I've squashed all the commits together; the tls model of the assembly
> > dispatch code and the dispatch tables have to match in order for things
> > to work.
> >
> > Since the revised patch is ~300K, I've attached it to bugzilla:
> > https://bugs.freedesktop.org/attachment.cgi?id=44777
> >
> 
> Sorry for replying so late but i think the root issue is somewhere
> else, i can't reproduce the bug here with the example program.

Hm.  What distro/libc/libstdc++/mesa are you using?  I presume you've
checked, but Fedora at least doesn't seem to enable tls on their mesa
builds.

It would be interesting to know what's different :).

>  Also
> initial-exec is allowed in dynamic librairy but it should be used
> scarcely and likely the only one allowed to do so would be libGL see
> 
> http://www.winehq.org/pipermail/wine-devel/2003-February/014738.html
> 

Ah!  I didn't find that when trying to hunt this down, and I *was* a bit
confused by the difference between the TLS ABI as described in Ulrich's
pdf and the code as manifest in glibc's loader.

> That being said, given we use PIC i don't think there is any
> difference in produced code btw initial-exec and global-dynamic (at
> least toy example don't show any).

I'm surprised here - initial-exec and global-dynamic should be
generating different code.  My understanding is that global-dynamic
requires at least one function call, whereas initial-exec should
generate a statically-calculable offset from the TCB (the reason why the
x86 runtime dispatch asm patching works), the address of which should be
stored in a register even in PIC code.

Certainly the object gets different flags; libGL using the initial-exec
model (correctly) has the STATIC_TLS DT_FLAG defined.

We have been seeing these crashes in Ubuntu and Debian and relaxing the
TLS model resolves the crashes.  It's possible that this is caused
somewhere else in the stack, though.  I'll have a further poke.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110331/103ce93d/attachment.pgp>