On Wed, Mar 30, 2011 at 8:18 PM, Christopher James Halse Rogers <christopher.halse.rog...@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.rog...@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.rog...@canonical.com wrote: >> >> > > From: Christopher James Halse Rogers >> >> > > <christopher.halse.rog...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
