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 v2 0/10] Tilera (and Linux asm-generic) support for glibc


On Saturday 12 November 2011, Joseph S. Myers wrote:
> There's no need to overstate your case by listing architectures with no 
> MMU or with no copyright assignment for the GCC and Binutils ports.  
> Architectures with no MMU are completely irrelevant to glibc.  The lack of 
> upstream tool ports may not be an automatic blocker to adding an 
> architecture to glibc's ports, but it certainly makes such a port less 
> useful and harder for people to test.

Yes, good point. So openrisc, c6x and lm32 are not relevant here since they
lack MMU support at the moment (this can certainly change in the future).
I don't know which of the MMU based ones have copyright assignment, but I
would expect to see that happen eventually for unicore{32,64} and
hexagon, less likely for nios2-mmu. 

> I have not seen an ARMv8 ARM or ABI specifications, but I doubt it would 
> make sense for a 64-bit ARM port to be separate from the 32-bit port; 
> presumably it would be desirable to be able to have one set of installed 
> headers working with both -m32 and -m64, just as for x86_64, Power 
> Architecture and other such cases, and various other files will probably 
> be shared between 32-bit and 64-bit variants.  This is similar to Roland's 
> observation that most if not all x32 code belongs with the x86_64 port 
> <http://sourceware.org/ml/libc-alpha/2011-07/msg00132.html>.

The armv8 code base is currently separate from the 32 bit arm in both kernel
and gcc, I assume the same is true for glibc. I would like to keep it this
way for the kernel, because the syscall ABI, the ELF ABI and the instruction
set are all very different from ARM, while there is very little code that
can actually be shared. In gcc, the tradeoff apparently is similar, and
I don't expect them to change that either. If we ever get a -m32/-m64 switch
on armv8, that is more likely to use only the full 64 bit instruction set
with either a ILP32 or LP64 ABI, but not the old instruction set.

In glibc you may of course still want to install both sets of header
files, like you would ideally do in an old-style ia64/i386 environment.

	Arnd


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