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
From d55d11080e8e8d0f4b6d832d4020787c42ba9943 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guil...@debian.org>
Date: Fri, 28 May 2021 04:07:49 +0200
Subject: [PATCH] arch: Add support for ARC CPU
This is based on the ARCv2 32-bit little-endian hard-float ISA.
Closes: #980963
Based-on-patch-by: Alexey Brodkin <alexey.brod...@synopsys.com>
---
data/cputable | 1 +
scripts/t/Dpkg_Arch.t | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/data/cputable b/data/cputable
index 05d2a44b2..b25b97211 100644
--- a/data/cputable
+++ b/data/cputable
@@ -22,6 +22,7 @@ i386 i686 (i[34567]86|pentium) 32 little
ia64 ia64 ia64 64 little
alpha alpha alpha.* 64 little
amd64 x86_64 (amd64|x86_64) 64 little
+arc arc arc 32 little
armeb armeb arm.*b 32 big
arm arm arm.* 32 little
arm64 aarch64 aarch64 64 little
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index 4f26778aa..be83dc2eb 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
use strict;
use warnings;
-use Test::More tests => 17914;
+use Test::More tests => 18407;
use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
debarch_eq debarch_is debarch_is_wildcard
@@ -187,7 +187,7 @@ foreach my $arch (@valid_arches) {
"bijective triplet $triplet to tuple @tuple");
}
-is(scalar @valid_arches, 539, 'expected amount of known architectures');
+is(scalar @valid_arches, 554, 'expected amount of known architectures');
{
local $ENV{CC} = 'false';
--
2.32.0.rc0.200.g928e72b83f
