This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH/RFC] Glibc Support for Thread Local Storage Descriptors in ARM platform
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Glauber de Oliveira Costa <glommer at gmail dot com>, libc-ports at sources dot redhat dot com, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, aldenor at gmail dot com
- Date: Fri, 22 Sep 2006 04:46:13 -0300
- Subject: Re: [PATCH/RFC] Glibc Support for Thread Local Storage Descriptors in ARM platform
- Organization: Red Hat OS Tools Group
- References: <5d6222a80608151205h4182fe93v6bf72f6faba3b4cb@mail.gmail.com> <20060921133639.GA21128@nevyn.them.org>
On Sep 21, 2006, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Aug 15, 2006 at 04:05:56PM -0300, Glauber de Oliveira Costa wrote:
>> libc-generic: contains some code that should be applied to the libc
>> generic tree, by anyone willing to test TLS descriptors. It is
>> basically the same code Oliva wrote for x86{,_64}, and it's already
>> being discussed for merging in the main tree.
> Did anything ever come of this?
Nope, the patches have been largely ignored :-(
>> arm-tlsdesc: contains the specific code, for which I expect the most
>> comments from people in this list.
> I don't have much in the way of comments. The amount of new code in
> sysdeps/arm/tlsdesc.c seems excessive; I don't see anything
> ARM-specific about it, so perhaps it should have been part of the
> libc-generic bits, or reused directly from sysdeps/i386/.
You're absolutely correct, but I don't try to do what feels correct to
me, and instead follow the recommendations that Uli gave me, and I
suggested Glauber to follow the same approach.
The hashtable code in tlsdesc.c definitely ought to be in
sysdeps/generic, but given that the patches for the so-called relevant
architectures containing such code have been largely ignored, and my
instructions for embedded ports were to keep in machine-specific code
anything that wasn't used in any of the relevant ports. So I
suggested Glauber to do that, in spite of both of us feeling that this
was nonsensical.
> There are a few coding style problems, but I'm not going to go
> through them until the basic idea is accepted for the libc generic
> pieces.
FWIW, I've re-tested my x86 and x86_64 changes last weekend and found
them to no longer work on x86_64 because of changes in setjmp/longjmp,
so I'll need to post an updated patch soon. I'll then split things up
a bit further, which might hopefully enable the dependencies of this
patch to be accepted even if the meat of the changes to x86 and x86_64
is deferred further.
--
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}