Re: Bug#980963: dpkg: Please add ARC architecture

[Vineet Gupta <Vineet.Gupta1@synopsys.com>]

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