On 3/4/21 3:56 PM, Vineet Gupta wrote: >> Also just to make sure, the GNU triplets are: >> >> arc-linux-gnu >> arceb-linux-gnu >> No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right? > > Actually it seems we are missing hardfloat here: ARC glibc/gcc support > it very well and should be default for any reasonable performance. > > So I think we should add > arc-linux-gnuhf > arceb-linux-gnuhf > > BTW I have oce question: where does one select what default toggles to > build the entire software stack with (say -mcpu etc). Does this rely > on toolchain driver default to DRTH. One of my problems with > rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it > there (and planning to upstream the gcc driver patch).
So here's the lay of the land, apologies for the long email, and if some/most of below is not directly relevant to dpkg bug, but I'll provide the background so we are all on same page. We've had 3 revisions of the ISA and ensuing multiple processors in last 15 years: ISA Implementations/Processors (Linux capable) ------ --------------------------------------------------------------- ARCompact ARC700 ARCv2 HS38x/HS48x ARCv3:32-bit HS58MP ARCv3:64-bit HS68MP - ARCompact is legacy and no new development needed including debian port. - Code for one ISA is not compatible with priors, mainly due to addition of new instructions. In fact given the configurability of the ISA itself (for better or worse), one could end up 2 non-compatible variants of same ISA (think double load/store instructions in ARCv2). But the port can assume the all encompassing super-set of the ISA as baseline. - ARCv3 is currently under development / pre-production but should be kept in mind as it is knocking on the door already. In terms of the ABI critical flavors: there's little/big endian and soft/hard-float. - Again big endian debian is not needed - mainly because of number of customer engagements and resourcing needed to support it - ARCv2 hard-float ABI is same as soft - FPU shares the same register file so the calling conventions are same. However the triplet is different arc-linux-gnuhf [1] as libraries for hard won't run on a soft-float system due to lack of emulation etc. - ARCv3 does have a dedicated FP register file so there's soft and hard ABIs So given all of this, I'd like to propose ARCv2 port with hard-float as baseline. We don't bother with Big-endian. A soft-float would be desirable for debugging and fall-back but not necessary from feature pov. I'm open to port names as maintainers feel appropriate - but stick with current triplets arc-gnu-linux / arc-gnu-linuxhf for ARCv2. For ARCv3, we could have arc64* / arc32* Please let me know if this makes sense. Once we agree, we can start off with requesting changes to GNU config project. Thx, -Vineet [1] I don't see the arc hf explicitly @ https://git.savannah.gnu.org/cgit/config.git/tree/testsuite/config-sub.data