don't accept IE relocs for module that has dynamic TLS blocks

Alexandre Oliva aoliva@redhat.com
Tue Oct 10 07:57:00 GMT 2006


On Feb  6, 2006, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Sep 22, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Sep 17, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>> The patch also adds a test to fix a problem I ran into while testing
>>>> these optimizations, that turned out to be possible to trigger with
>>>> the old code.

>> Split out, per Roland's request.

>> As shown in the testcase, when we accept a relocation to static TLS,
>> we must make sure the referenced symbol has never been assigned to
>> dynamic TLS before.  This requires __tls_get_addr() to commit a
>> module to a new state in which it's no longer eligible for static
>> TLS, and have the code used to test for static TLS adjusted,
>> especially the code that tries to commit a module to static TLS.

> Any reason why this hasn't been reviewed or installed yet?  It's been
> pending for a while, and it would be nice if GLIBC 2.4 had this fix.

> As shown in the testcase, when we accept a relocation to static TLS,
> we must make sure the referenced symbol has never been assigned to
> dynamic TLS before.  This requires __tls_get_addr() to commit a
> module to a new state in which it's no longer eligible for static
> TLS, and have the code used to test for static TLS adjusted,
> especially the code that tries to commit a module to static TLS.

Ping?

Re-tested updated patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-static-tls-after-dynamic.patch
Type: text/x-patch
Size: 9920 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20061010/e6b975ed/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


More information about the Libc-alpha mailing list