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@xxxxxxxxxxxxxxxx _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
