Bug#980963: dpkg: Please add ARC architecture

[Guillem Jover]

Hi!

On Mon, 2021-05-24 at 20:41:23 +0000, Vineet Gupta wrote:
> 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.

I discussed this today with Vineet on IRC in #debian-bootstrap, to try
to clarify some things, and this is the summary I think:

* ARCv2 32-bit little-endian

  - The arch based on ARCv2 32-bit is going to be little-endian, and
    ideally will be hard-float, but that's pending on a patch for gcc,
    to flip the default from soft-float. From what I understand while
    hard and soft-float are ABI compatible in the ISA and calling
    convention sense, they are not ABI compatible in the object
    linking sense, and while I guess this could also perhaps be lifted,
    it's not currently the case. My concern is that adding the support
    before the default has been switched might mean "ABI incompatible"
    architectures if we cannot link objects. Vineet, mentioned that
    they might be fine settling with soft-float in that case, even
    with the performance penalty implied (in that case, personally I
    think adding the -gnuhf triplet would be better, but I'd not be
    going to be doing the work, so… :). The patch is supposed to be
    sent upstream around next week or so. I'd prefer to wait what
    ends up happening there, TBH, before committing the support to
    dpkg. As I've mentioned I'm fine with committing it once it hits
    upstream git though.
  - The triplet would be «arc-linux-gnu», the Debian architecture
    would be «arc».

* ARCv3 32/64-bit little-endian

  - These are still in the works, but there's already a GNU triplet
    «arc64-linux-gnu» in GNU config for the 64-bit CPU, the idea is
    for the 32-bit one to use «arc32-linux-gnu».
  - To avoid confusion we discussed that it might make sense to use
    as Debian arch names arc32v3 and arc64v3, to distinguish it
    clearly from the ARCv2 arch, following the existing pattern in
    MIPS r6. Otherwise placing the bitness after the ISA version makes
    for an even more confusing name.
  - This can be proposed for addition once the upstream toolchain has
    support for it, but given that the overall architectures have been
    clarified now, that should then be swift.

I'm attaching the tentative patch for the «arc» arch.

Thanks,
Guillem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arch-Add-support-for-ARC-CPU.patch
Type: text/x-diff
Size: 1602 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20210528/1b7f1784/attachment.bin>