[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?


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: