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