Bug#980963: dpkg: Please add ARC architecture

[Vineet Gupta]

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