This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/RFC] Glibc Support for Thread Local Storage Descriptors in ARM platform


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}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]