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

Jerome Glisse j.glisse at gmail.com
Wed Mar 30 18:07:22 PDT 2011


On Wed, Mar 30, 2011 at 8:18 PM, Christopher James Halse Rogers
<christopher.halse.rogers at canonical.com> wrote:
> 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 :).

I will double check but i am pretty sure i used my own compiled
version with tls but i have many concurrent build of mesa laying
around not all with same flags.

>>  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.
>

It seems gcc was ignoring initial-exec if not specified everywhere the
value was, i should have double checked that. I do see different code
in the toy example. Initial-exec version is more efficient. I will
take a look at what might goes wrong with tls here on fedora.

Cheers,
Jerome


More information about the mesa-dev mailing list