Re: Bug#807340: dpkg: please add MIPS R6 support
On Tue, Dec 22, 2015 at 9:10 AM, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Tue, 2015-12-08 at 01:07:16 +0800, YunQiang Su wrote:
>> Package: src:dpkg
>> Version: 1.18.3
>
>> We are working on add basic support of MIPS R6 support to Debian.
>> Please add the support of R6 architectures to dpkg.
>>
>> About MIPS R6:
>> MIPS R6 is a new release of MIPS32 and MIPS64.
>> R6 is not fully compatible with R5-,
>> as it adds and *removes* some instructions, and add emulation
>> of the removed instructions in kernel,
>> so old binaries can still run on new R6 CPUs.
>>
>> While for the new CPUs, we still wish they can have their own architectures.
>
> I feel quite uneasy with these kind of architecture requests, when they
> seem to be mostly just new ISAs of pre-existing CPUs. More so when there's
> kernel emulation for missing instructions and such.
>
> Are the removed instructions widely used? Are they emitted as part of
> normal gcc output, or are they contained in very specific areas, that
> providing optimized versions of those packages using hwcap support
> would mean no degradation at all?
https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/documentation/MD00087-2B-MIPS64BIS-AFP-06.04.pdf
As this document says: even `add' and `ABS.fmt' areve removed.
You can search by words ` removed in Release 6'.
>
> I see that config.guess/config.sub already support this, I've had no
> time to check what's the status on the rest of the toolchain?
At least gcc/binutils/glibc/linux support these new architectures.
For other packages, we can add support for them by autoreconf.
>
> Also I guess this is extremely new, but before considering to add this
> stuff, I'd also like to know the stance of the pre-existing mips porters
> on these. Should we instead try to target a bump of the MIPS ISAs?
Bump current MIPS ISAs will not a good idea, as the current hardware
will not be workable at all.
Let's CC to debian-mips.
>
>> diff --git a/cputable b/cputable
>> index 676dcd7..f9f7f63 100644
>> --- a/cputable
>> +++ b/cputable
>> @@ -29,6 +29,10 @@ mips mips mips(eb)? 32 big
>> mipsel mipsel mipsel 32 little
>> mips64 mips64 mips64 64 big
>> mips64el mips64el mips64el 64 little
>> +mips32r6 mipsisa32r6 mipsisa32r6 ` 32 big
>
> As Helmut pointed out on IRC, there's a spurious ` here.
Ohh, it is a typo.
>
>> diff --git a/triplettable b/triplettable
>> index 7257744..a5ec5f1 100644
>> --- a/triplettable
>> +++ b/triplettable
>> @@ -9,10 +9,14 @@ musleabihf-linux-arm musl-linux-armhf
>> +gnuabin32-linux-mips64r6 mipsn32r6
>> +gnuabin32-linux-mips64r6el mipsn32r6el
>> +gnuabi64-linux-mips64r6 mips64r6
>> +gnuabi64-linux-mips64r6el mips64r6el
>
> Are you really going to try to get all these arches up? Otherwise I'd
> avoid the clutter.
We don't need so many architectures.
While they may be needed in future.
The most high priority one is mips64r6el and then mips32r6el.
If you still want to remove some, please keep these 2 at least.
I still wish you can keep all of them.
>
> Thanks,
> Guillem
--
YunQiang Su
Reply to: