RE: dpkg: Please add ARC architecture

RE: dpkg: Please add ARC architecture

[Alexey Brodkin]

Hello,

Any chances to get updates on this one some time soon?

Regards,
Alexey
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Helmut Grohne]

On Sat, Feb 06, 2021 at 07:25:35PM +0000, Alexey Brodkin wrote:
> Any chances to get updates on this one some time soon?

No. The triplet cannot be changed once added. Therefore, the addition is
often deferred. The absence of the triplet can easily be worked around.
A bootstrap can be prototyped already. A major missing piece though is
glibc 2.32 being packaged in Debian. That likely is a prerequisite for
resolving this bug.

Things that often need architecture-specific support for a new
architecture include:
 * guile-X.Y (cross support)
 * libgc
 * libxcrypt (symbols)
 * nspr
 * openssl (packaging)

Are any of these fixed or confirmed working for arc?

I suggest that you coordinate with Vineet Gupta as he is already working
on this.

Helmut


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Vineet Gupta]

On Wed, 3 Mar 2021 19:04:36 +0100 Helmut Grohne <helmut@subdivi.de> wrote:
 > On Sat, Feb 06, 2021 at 07:25:35PM +0000, Alexey Brodkin wrote:
 > > Any chances to get updates on this one some time soon?
 >
 > No. The triplet cannot be changed once added. Therefore, the addition is
 > often deferred. The absence of the triplet can easily be worked around.
 > A bootstrap can be prototyped already. A major missing piece though is
 > glibc 2.32 being packaged in Debian. That likely is a prerequisite for
 > resolving this bug.
 >
 > Things that often need architecture-specific support for a new
 > architecture include:
 > * guile-X.Y (cross support)
 > * libgc
 > * libxcrypt (symbols)
 > * nspr
 > * openssl (packaging)
 >
 > Are any of these fixed or confirmed working for arc?
 >
 > I suggest that you coordinate with Vineet Gupta as he is already working
 > on this.

The current WIP is at

https://github.com/foss-for-synopsys-dwc-arc-processors/rebootstrap.git

The deal breaker is glibc support since debian is at 2.31 while ARC port was merged in 2.32. So here we patch in the entire ARC port :-)

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Alexey Brodkin]

Hi Helmut,

> On Sat, Feb 06, 2021 at 07:25:35PM +0000, Alexey Brodkin wrote:
> > Any chances to get updates on this one some time soon?
> 
> No. The triplet cannot be changed once added. Therefore, the addition is
> often deferred. The absence of the triplet can easily be worked around.
> A bootstrap can be prototyped already. A major missing piece though is
> glibc 2.32 being packaged in Debian. That likely is a prerequisite for
> resolving this bug.

Well not sure why there's a dependency on glibc as w/o ARC target support
in dpkg nothing could be built for ARC. For example I did built Binutils
with fixed dpkg.

> Things that often need architecture-specific support for a new
> architecture include:
>  * guile-X.Y (cross support)
>  * libgc

Above 2 are not [yet] supported but seems to be easy ones.

>  * libxcrypt (symbols)

Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC since 2018, see:
https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657

>  * nspr

Done in 2019, see https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

>  * openssl (packaging)

Not sure what needs to be done here as I know we build a lot of complex
things with OpenEmbedded/Yocto and openssl libs are being built for sure.

> Are any of these fixed or confirmed working for arc?

See above, quite some do work.
 
-Alexey
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Helmut Grohne]

Hi Alexey,

On Wed, Mar 03, 2021 at 07:35:39PM +0000, Alexey Brodkin wrote:
> Well not sure why there's a dependency on glibc as w/o ARC target support
> in dpkg nothing could be built for ARC. For example I did built Binutils
> with fixed dpkg.

There is no hard dependency in that direction. Just pushback on adding
lots of Debian architectures that never really take off. For instance,
or1k was never fully bootstrapped. It'll be merged. Just not now. (Not
speaking as a dpkg maintainer here, just telling what will happen from
experience.)

> > Things that often need architecture-specific support for a new
> > architecture include:
> >  * guile-X.Y (cross support)
> >  * libgc
> 
> Above 2 are not [yet] supported but seems to be easy ones.

guile-X.Y is quite mechanical, yes. libgc can be a little more
difficult.

> >  * libxcrypt (symbols)
> 
> Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC since 2018, see:

https://tracker.debian.org/pkg/libxcrypt

> https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657

This should be unneeded. libgpg-error now defaults to
force_use_syscfg=no and no longer needs arch-specific changes.

> >  * nspr
> 
> Done in 2019, see https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

Great.

> >  * openssl (packaging)
> 
> Not sure what needs to be done here as I know we build a lot of complex
> things with OpenEmbedded/Yocto and openssl libs are being built for sure.

https://sources.debian.org/src/openssl/1.1.1j-1/debian/patches/debian-targets.patch/

> > Are any of these fixed or confirmed working for arc?
> 
> See above, quite some do work.

Impressive. Some work is left. What also is left is demonstrating that
it actually works. It seems that Vineet is working on integrating it.

Helmut


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Guillem Jover]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

Hi!

On Sun, 2021-01-24 at 23:36:52 +0300, Alexey Brodkin wrote:
> Package: dpkg
> Version: 1.19.7ubuntu3-1~202101232134~ubuntu20.04.1
> Severity: wishlist
> Tags: patch

> ARC architecture seem to match requirements for being added to the dpkg
> (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F):
> 
>  * GNU triplet is there since 2013,
>    see: https://git.savannah.gnu.org/cgit/config.git/commit/?id=986360de6e412cbed27dbe2dbfb64ddbd18e7370
>  * Binutils, GCC & uClibc support ARC for many years now,
>    glibc 2.32 finally gained ARC support, see https://lists.gnu.org/archive/html/info-gnu/2020-08/msg00002.html 

Sorry, didn't reply up to now due to the freeze, this not looking
ready yet (as glibc is not even in Debian), but mostly because it
slipped my mind, but that kind of blocks progress on your side.
So let's see. :)

Or, were you looking to get this included for bullseye? (I think this
would not qualify, but, I think we might have done exceptions in such
cases in the past.)

Is the ABI fully stabilized now?

> >From 96523e18473b56743bf2f7d308c2d786f337e52e Mon Sep 17 00:00:00 2001
> From: Alexey Brodkin <abrodkin@synopsys.com>
> Date: Sun, 24 Jan 2021 00:34:52 +0300
> Subject: [PATCH] Add ARC architecture

> diff --git a/data/cputable b/data/cputable
> index 9f2a8e0e4..114a66ecb 100644
> --- a/data/cputable
> +++ b/data/cputable
> @@ -20,6 +20,8 @@ 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
> +arceb		arc		arceb.*			32	big
>  armeb		armeb		arm.*b			32	big
>  arm		arm		arm.*			32	little
>  arm64		aarch64		aarch64			64	little

This looked incorrect, as it ends up not being a bijective relation,
so the lines need to be swapped. The problem is that the comments do
not explain this nor the test suite checks. So I improved both with the
attached patches, which I'll commit into master once I open it up for
1.21.x.

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?

Thanks,
Guillem

[-- Attachment #2: 0001-test-Add-unit-tests-for-architecture-bijective-mappi.patch --]
[-- Type: text/x-diff, Size: 2616 bytes --]

From f5cae4f8fc4ef67ec5e26dffeb3b3c540949f554 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guillem@debian.org>
Date: Mon, 25 Jan 2021 05:37:06 +0100
Subject: [PATCH] test: Add unit tests for architecture bijective mapping
 property

The architectures need to have the bijective property when converting
back and forth from the Debian arch name to the GNU triplet. Enforce
this in the test suite to make it easier to guarantee this when adding
new architectures to the tables.
---
 scripts/t/Dpkg_Arch.t | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index a3a9e6fee..4f26778aa 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 => 16836;
+use Test::More tests => 17914;
 
 use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
                         debarch_eq debarch_is debarch_is_wildcard
@@ -24,9 +24,12 @@ use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
                         debarch_to_abiattrs debarch_to_cpubits
                         debarch_list_parse
                         debtuple_to_debarch gnutriplet_to_debarch
+                        debtuple_to_gnutriplet gnutriplet_to_debtuple
                         get_host_gnu_type
                         get_valid_arches));
 
+my @valid_arches = get_valid_arches();
+
 sub get_valid_wildcards
 {
     my %wildcards;
@@ -37,7 +40,7 @@ sub get_valid_wildcards
         any-any-any-any
     );
 
-    foreach my $archname (get_valid_arches()) {
+    foreach my $archname (@valid_arches) {
         my @tuple = debarch_to_debtuple($archname);
 
         my @wildcards_arch = (
@@ -174,7 +177,17 @@ is(gnutriplet_to_debarch(undef), undef, 'undef gnutriplet');
 is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown gnutriplet');
 is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet');
 
-is(scalar get_valid_arches(), 539, 'expected amount of known architectures');
+foreach my $arch (@valid_arches) {
+    my @tuple = debarch_to_debtuple($arch);
+    is(debtuple_to_debarch(@tuple), $arch,
+       "bijective arch $arch to tuple @tuple");
+
+    my $triplet = debtuple_to_gnutriplet(@tuple);
+    is_deeply([ gnutriplet_to_debtuple($triplet) ], \@tuple,
+              "bijective triplet $triplet to tuple @tuple");
+}
+
+is(scalar @valid_arches, 539, 'expected amount of known architectures');
 
 {
     local $ENV{CC} = 'false';
-- 
2.30.1


[-- Attachment #3: 0001-arch-Clarify-that-the-regex-columns-need-to-be-order.patch --]
[-- Type: text/x-diff, Size: 1809 bytes --]

From 06cf2888850c63c59bf75820d2b69159684e6ba3 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guillem@debian.org>
Date: Mon, 25 Jan 2021 05:41:00 +0100
Subject: [PATCH] arch: Clarify that the regex columns need to be ordered to
 match first

The entries are used in a first match order, so the regexes need to
be listed from most specific to less specific.
---
 data/cputable | 3 ++-
 data/ostable  | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/data/cputable b/data/cputable
index 9f2a8e0e4..505641659 100644
--- a/data/cputable
+++ b/data/cputable
@@ -11,7 +11,8 @@
 # - Column 2 is the GNU name for the CPU, used to output build, host and
 #   target variables in ‘dpkg-architecture’.
 # - Column 3 is an extended regular expression used to match against the
-#   CPU part of the output of the GNU config.guess script.
+#   CPU part of the output of the GNU config.guess script. The order of
+#   this column is important as it is used in a first match basis.
 # - Column 4 is the size (in bits) of pointers.
 # - Column 5 is the endianness (byte ordering in numbers).
 #
diff --git a/data/ostable b/data/ostable
index 99c1f889d..055363bb9 100644
--- a/data/ostable
+++ b/data/ostable
@@ -11,7 +11,8 @@
 # - Column 2 is the GNU name for the system, used to output build, host and
 #   target variables in ‘dpkg-architecture’.
 # - Column 3 is an extended regular expression used to match against the
-#   system part of the output of the GNU config.guess script.
+#   system part of the output of the GNU config.guess script. The order of
+#   this column is important as it is used in a first match basis.
 #
 # <Debian name>		<GNU name>		<config.guess regex>
 eabi-uclibc-linux	linux-uclibceabi	linux[^-]*-uclibceabi
-- 
2.30.1


[-- Attachment #4: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Vineet Gupta]

Hi Guillem,

On 3/4/21 5:55 AM, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2021-01-24 at 23:36:52 +0300, Alexey Brodkin wrote:
>> Package: dpkg
>> Version: 1.19.7ubuntu3-1~202101232134~ubuntu20.04.1
>> Severity: wishlist
>> Tags: patch
> 
>> ARC architecture seem to match requirements for being added to the dpkg
>> (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F):
>>
>>   * GNU triplet is there since 2013,
>>     see: https://git.savannah.gnu.org/cgit/config.git/commit/?id=986360de6e412cbed27dbe2dbfb64ddbd18e7370
>>   * Binutils, GCC & uClibc support ARC for many years now,
>>     glibc 2.32 finally gained ARC support, see https://lists.gnu.org/archive/html/info-gnu/2020-08/msg00002.html
> 
> Sorry, didn't reply up to now due to the freeze, this not looking
> ready yet (as glibc is not even in Debian), but mostly because it
> slipped my mind, but that kind of blocks progress on your side.
> So let's see. :)
> 
> Or, were you looking to get this included for bullseye? (I think this
> would not qualify, but, I think we might have done exceptions in such
> cases in the past.)

We don' have a timelime, but the sooner the better ;-)
I just want to flush out any missing pieces from ARC side of the things.

> Is the ABI fully stabilized now?

It is. One thing to note is that ARC follows the 64-bit time_t/offsets, 
for 32-bit arches, enabled by glibc 2.32 (and that is the only glibc ABI 
we support). FWIW RV32 being th eonly other 32-bit arch (so far) to do 
that. I'm not sure if the debian ecosystem is prepared for this in 
general (for 32-bit arches). At the time fixes were neede in simplest of 
things like busybox so I'm wondering if what support if needed elsewhere 
or is it there already.


>> >From 96523e18473b56743bf2f7d308c2d786f337e52e Mon Sep 17 00:00:00 2001
>> From: Alexey Brodkin <abrodkin@synopsys.com>
>> Date: Sun, 24 Jan 2021 00:34:52 +0300
>> Subject: [PATCH] Add ARC architecture
> 
>> diff --git a/data/cputable b/data/cputable
>> index 9f2a8e0e4..114a66ecb 100644
>> --- a/data/cputable
>> +++ b/data/cputable
>> @@ -20,6 +20,8 @@ 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
>> +arceb		arc		arceb.*			32	big
>>   armeb		armeb		arm.*b			32	big
>>   arm		arm		arm.*			32	little
>>   arm64		aarch64		aarch64			64	little
> 
> This looked incorrect, as it ends up not being a bijective relation,
> so the lines need to be swapped. The problem is that the comments do
> not explain this nor the test suite checks. So I improved both with the
> attached patches, which I'll commit into master once I open it up for
> 1.21.x.

Thx. We are debian noobs so please feel free to massage them for 
correctness and/or feel free to ask us to rework.


> 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).

Thx,
-Vineet

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Vineet Gupta]

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

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

[Guillem Jover]

[-- Attachment #1: Type: text/plain, Size: 5715 bytes --]

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

[-- Attachment #2: 0001-arch-Add-support-for-ARC-CPU.patch --]
[-- Type: text/x-diff, Size: 1653 bytes --]

From d55d11080e8e8d0f4b6d832d4020787c42ba9943 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guillem@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.Brodkin@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


[-- Attachment #3: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[Vineet Gupta]

Hi Guillem,

On 5/27/21 8:50 PM, Guillem Jover wrote:
> 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».

FWIW gcc patch is now in mainline (I've requested Claudiu for backport)

2021-06-02 46d04271a498 ARC: gcc driver default to hs38_linux

Thx,
-Vineet

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc