[PATCH v4 02/15] ARC: ABI Implementation

[Vineet Gupta]

On 3/26/20 11:48 AM, Joseph Myers wrote:
> 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.

I added bits in sysdeps/arc/configure.ac and corresponding conditional in
shlib-version. But I have to ask (embarrassingly). how to I regenerate
sysdeps/arc/configure.  I tried all possibe autoconf cmds with toggles (both at
top and in sysdeps/arc) and even reran configure in build tree with
--enable-maintainer-mode


>> 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).

I'll drop ARC700 support for now and we can add it later if need be. I suppose
there are no other ABI/versioning/compat complications in such an approach.