* RE: dpkg: Please add ARC architecture @ 2021-02-06 19:25 ` Alexey Brodkin 2021-03-03 18:04 ` Bug#980963: " Helmut Grohne 0 siblings, 1 reply; 11+ messages in thread From: Alexey Brodkin @ 2021-02-06 19:25 UTC (permalink / raw) To: 980963; +Cc: linux-snps-arc, Guillem Jover 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-02-06 19:25 ` dpkg: Please add ARC architecture Alexey Brodkin @ 2021-03-03 18:04 ` Helmut Grohne 2021-03-03 18:55 ` Vineet Gupta 2021-03-03 19:35 ` Alexey Brodkin 0 siblings, 2 replies; 11+ messages in thread From: Helmut Grohne @ 2021-03-03 18:04 UTC (permalink / raw) To: Alexey Brodkin, 980963; +Cc: Guillem Jover, linux-snps-arc, Vineet Gupta 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-03-03 18:04 ` Bug#980963: " Helmut Grohne @ 2021-03-03 18:55 ` Vineet Gupta 2021-03-03 19:35 ` Alexey Brodkin 1 sibling, 0 replies; 11+ messages in thread From: Vineet Gupta @ 2021-03-03 18:55 UTC (permalink / raw) To: 980963; +Cc: arcml 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-03-03 18:04 ` Bug#980963: " Helmut Grohne 2021-03-03 18:55 ` Vineet Gupta @ 2021-03-03 19:35 ` Alexey Brodkin 2021-03-03 19:54 ` Helmut Grohne 1 sibling, 1 reply; 11+ messages in thread From: Alexey Brodkin @ 2021-03-03 19:35 UTC (permalink / raw) To: Helmut Grohne; +Cc: Guillem Jover, linux-snps-arc, Vineet Gupta, 980963 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-03-03 19:35 ` Alexey Brodkin @ 2021-03-03 19:54 ` Helmut Grohne 0 siblings, 0 replies; 11+ messages in thread From: Helmut Grohne @ 2021-03-03 19:54 UTC (permalink / raw) To: Alexey Brodkin; +Cc: Guillem Jover, linux-snps-arc, Vineet Gupta, 980963 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture [not found] <161152061283.11410.4872085138884291562.reportbug@abrodkin-5550.internal.synopsys.com> 2021-02-06 19:25 ` dpkg: Please add ARC architecture Alexey Brodkin @ 2021-03-04 13:55 ` Guillem Jover 2021-03-04 23:56 ` Vineet Gupta 1 sibling, 1 reply; 11+ messages in thread From: Guillem Jover @ 2021-03-04 13:55 UTC (permalink / raw) To: Alexey Brodkin, 980963; +Cc: Vineet Gupta, linux-snps-arc [-- 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-03-04 13:55 ` Guillem Jover @ 2021-03-04 23:56 ` Vineet Gupta 2021-03-26 17:39 ` Vineet Gupta 0 siblings, 1 reply; 11+ messages in thread From: Vineet Gupta @ 2021-03-04 23:56 UTC (permalink / raw) To: Guillem Jover, 980963, Alexey Brodkin; +Cc: linux-snps-arc, Helmut Grohne 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-03-04 23:56 ` Vineet Gupta @ 2021-03-26 17:39 ` Vineet Gupta 2021-05-24 20:41 ` Vineet Gupta 0 siblings, 1 reply; 11+ messages in thread From: Vineet Gupta @ 2021-03-26 17:39 UTC (permalink / raw) To: Guillem Jover, 980963, Alexey Brodkin Cc: linux-snps-arc, Helmut Grohne, Claudiu Zissulescu, debian-cross 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-03-26 17:39 ` Vineet Gupta @ 2021-05-24 20:41 ` Vineet Gupta 2021-05-28 3:50 ` Guillem Jover 0 siblings, 1 reply; 11+ messages in thread From: Vineet Gupta @ 2021-05-24 20:41 UTC (permalink / raw) To: Guillem Jover, 980963, Alexey Brodkin Cc: linux-snps-arc, Helmut Grohne, Claudiu Zissulescu, debian-cross 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-05-24 20:41 ` Vineet Gupta @ 2021-05-28 3:50 ` Guillem Jover 2021-06-02 20:05 ` Vineet Gupta 0 siblings, 1 reply; 11+ messages in thread From: Guillem Jover @ 2021-05-28 3:50 UTC (permalink / raw) To: Vineet Gupta, 980963 Cc: Alexey Brodkin, linux-snps-arc, Helmut Grohne, Claudiu Zissulescu, debian-cross [-- 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Bug#980963: dpkg: Please add ARC architecture 2021-05-28 3:50 ` Guillem Jover @ 2021-06-02 20:05 ` Vineet Gupta 0 siblings, 0 replies; 11+ messages in thread From: Vineet Gupta @ 2021-06-02 20:05 UTC (permalink / raw) To: Guillem Jover, Vineet Gupta, 980963, Alexey Brodkin, linux-snps-arc, Helmut Grohne, Claudiu Zissulescu, debian-cross 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-06-02 20:05 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <161152061283.11410.4872085138884291562.reportbug@abrodkin-5550.internal.synopsys.com> 2021-02-06 19:25 ` dpkg: Please add ARC architecture Alexey Brodkin 2021-03-03 18:04 ` Bug#980963: " Helmut Grohne 2021-03-03 18:55 ` Vineet Gupta 2021-03-03 19:35 ` Alexey Brodkin 2021-03-03 19:54 ` Helmut Grohne 2021-03-04 13:55 ` Guillem Jover 2021-03-04 23:56 ` Vineet Gupta 2021-03-26 17:39 ` Vineet Gupta 2021-05-24 20:41 ` Vineet Gupta 2021-05-28 3:50 ` Guillem Jover 2021-06-02 20:05 ` Vineet Gupta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.