This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc
On Mon, 14 Nov 2011, Arnd Bergmann wrote:
> 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
Are you able to post those patches somewhere?
I hope that if it's as different as you say (that is, "ARM" only in
marketing terms, not in terms of similarity to anything previously called
ARM), the GNU target triplet for 64-bit mode is not armv8*-*-* or anything
else starting with "arm", given that would match any number of cases all
over the place that test for arm*-*-*.... armv8*-*-* should clearly be v8
in the normal 32-bit mode.
> 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
Are the ABI and ISA specifications available somewhere? I couldn't find
them.
> 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.
How dissimilar are the instruction sets? The obvious comparison is SH64 -
which uses the same GCC back end and arch/ directory in the kernel, but
where some people have suggested there is sufficiently little similarity
to other versions of SH that having a separate back end would have been
better. Unfortunately I don't know enough about SH to judge that for
myself. (The Score port of GCC was an example that clearly did not belong
in one back end; until support for an older ISA variant was removed, all
the main hooks just selected at runtime between functions for two
different instruction sets. If the instruction sets are so different that
every function is just if (32-bit) 32-bit-func (); else 64-bit-func ();,
with nothing useful to share, then you definitely want two separate
ports.)
If ARMv8 supports the classic ARM and Thumb-2 instruction sets for 32-bit
code and if those have any new features compared to ARMv7, that of course
implies supporting ARMv8 properly includes support for those new features
in 32-bit code with the 32-bit back end (after all, you want to be able to
build code that dynamically dispatches based on the processor in use at
runtime, whether with STT_GNU_IFUNC or otherwise, so want one compiler to
support a range of 32-bit code generation from v4 through v8).
I suppose a key question is whether the 64-bit ISA has entirely new
instructions - not just a new encoding of largely existing instructions
like Thumb-2 was - in which case separate ports likely make sense - or
whether it has a large proportion of the old instructions with their
semantics changing in predictable ways that can be abstracted
appropriately in the compiler. (There is also the possibility of being
able to share some code between separate ports, as with the Tilera ports -
similar enough to share a lot of code in glibc and a smaller amount in GCC
(a shared generator for some tables that are different in the two ports),
but different enough to count as different targets.)
Presumably the actual patch submissions will come with clear rationale for
the approach taken, given that the recent Linux kernel trend has been to
unify formerly separate directories for 32-bit and 64-bit variants (and
MMU / no-MMU) of the same architecture, e.g. x86 unifying i386 and x86_64.
An ia16 port for GCC was also rejected because of a general view that it
would better be a -m16 mode in the i386 back end. I don't think there are
any existing GCC ports for which the 32-bit and 64-bit instruction sets
use different ports, and I think PA is the only one with 32-bit and 64-bit
variants but without -m32/-m64 options to choose between them (instead
requiring separate compilers for the two modes) - and that is probably
because 64-bit PA GNU/Linux hasn't got very far, while HP-UX uses
different object formats for 32-bit and 64-bit which makes a unified
compiler for those variants hard to achieve.
(Hybrid approaches include x86_64, with its own glibc port separate from
i386 but with all the installed headers supporting both 32-bit and 64-bit
modes and with the ports in others components shared.)
--
Joseph S. Myers
joseph@codesourcery.com