<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - initial-exec TLS model breaks dlopen'ed libGL" href="https://bugs.freedesktop.org/show_bug.cgi?id=35268#c29">Comment # 29</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - initial-exec TLS model breaks dlopen'ed libGL" href="https://bugs.freedesktop.org/show_bug.cgi?id=35268">bug 35268</a> from <a class="email" href="mailto:bugdal@aerifal.cx" title="Rich Felker <bugdal@aerifal.cx>"> Rich Felker</a> <pre>It turns out there's more code that needs to be refitted or removed from src/mapi/entry_*_tls.h, including powerpc64le asm I wasn't aware of before. There's a lot of code to generate executable stubs at runtime, but such generation is only a significant optimization when the TLS offset from the thread pointer is constant, and the whole point of this PR is that that assumption is invalid. Otherwise, the fallback case in entry.c of just handing out slots from a big static pool should perform just as well. Should I continue along the path of fixing the stub generation to use TLSDESC? Or just submit a match that removes all this stuff? On 32-bit x86 I think there's still a slight benefit of having it -- by generating the stubs dynamically, the absolute address of the GOT slots containing the TLS descriptor can be hard-coded in the stub, rather than requiring a fake call/pop to load the GOT address. But on x86_64 it should make no difference.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>