[PATCH v4 02/15] ARC: ABI Implementation

[Joseph Myers]

On Wed, 25 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> Hardware-wise, ARC can be configured to be LE or BE and software supports that
> (cfr Linux or uClibc). The initial glibc port was only aiming LE but we ended up
> with BE as well due to a customer engagement. And given much of ARC port is
> currently generic (minimal asm), no real change was needed except enabling it in
> this header. We do plan to officially support it so I guess we need some more
> changes in Documentation / ABI listing etc.

Yes, if you want to support BE then it should be documented as supported, 
it should have its own dynamic linker name (with consequent GCC change 
required to use that name) and it should have its own build in 
build-many-glibcs.py.

> Right, we've had 2 ARC ISA: current generation ARCv2 (basis for HS3x and HS4x
> processors) and the older ARCompact (ARC700 cores which run Linux and still
> supported e.g. in Mellanox NPS cores). From instruction set pov they are very
> similar (although not binary compatible).

If they're not binary compatible (so you can't have a binary that works on 
both) that indicates they should also be considered separate ABIs (so you 
have four dynamic linker names, each with corresponding build in 
build-many-glibcs.py, plus any other variants that are relevant to build 
in build-many-glibcs.py without being different ABIs, such as hard/soft 
float).

-- 
Joseph S. Myers
joseph@codesourcery.com