Hi Guillem, On 3/26/21 10:39 AM, Vineet Gupta wrote: > 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.
Further to my msg on IRC, we've gotten pretty far along with ARC rebootstrap [1]. It seems to build 151 packages before failing for perl and I see similar outcome for riscv64 (which is weird as perl should be supported there. Anyhow this is just a polite ping to make some progress on ARC. Thx, -Vineet [1] https://salsa.debian.org/vineetgarc/rebootstrap
