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

[Vineet Gupta <vgupta@synopsys.com>]

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