Re: [PATCH v4 02/15] ARC: ABI Implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

> 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, plus any other variants that are relevant to build 
in without being different ABIs, such as hard/soft 

Joseph S. Myers

linux-snps-arc mailing list

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux