Re: glibc am33 and cris architectures

[Hans-Peter Nilsson <hans-peter.nilsson@axis.com>]

> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Tue, 21 Feb 2012 16:21:12 +0100

> The am33 and cris glibc ports won't have worked since the 2.3-2.5 era for 
> lack of NPTL/TLS support.  They are currently on the deprecation list for 
> removal after glibc 2.16 is released 
> <http://sourceware.org/glibc/wiki/Deprecation>.  But given how long they 
> won't have worked, I wonder if we should just remove them now.

For CRIS, I'd suggest to do that.

>  Alexandre, 
> Hans-Peter - do you have, or know of, any near-term plans to bring your 
> respective ports up to date with NPTL and TLS support and updates for all 
> the other libc changes in the past several years?

JFTR, there's a local port, specific to CRIS v32 (a later
variant), with the glibc part based on an import of the
eglibc-2.9 branch.  Linux TLS support (yes, I do mean just the
kernel) is currently missing for CRIS.  That is, it's missing
for CRIS v10, the original GNU/Linux-capable variant
(disregarding earlier MMU-less variants): anyone interested is
advised to please use either $IRP or $BRP as the thread-pointer
register; use the CRIS v32 Linux support as a template with
minor changes in thread-pointer-setting and most changes for
restoring that register at return from interrupt or breakpoint
or syscall return.

GCC TLS support for CRIS v32 needs to be updated and committed
anyway, by itself the least complex part, but not trivial and
even that part is not imminent though hopefully will happen in
the first half of this year.  Still, no commitment for any work
in a time-frame I'd dare call near-term.  Thus, just a glibc
CRIS port update right now wouldn't do much good in practice.

When doing the (e)glibc import part of the TLS support, I
noticed how much had changed since last synch.  I suggest that
even if someone else were to do independent work, it'd be better
to start from scratch than be distracted by the half-way-commit
of the originally submitted code that's currently in place.
Best to remove it; it'll just bloat any CRIS-related patches.

brgds, H-P
(PS. but at least the binutils TLS part is all committed. :)