Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1380663 > unrolled thread

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

Started bykbuild test robot <fengguang.wu@intel.com>
First post2016-04-17 02:30 +0200
Last post2016-04-22 03:10 +0200
Articles 10 — 5 participants

Back to article view | Back to linux.kernel

Contents

  {standard input}:136: Error: number (0x9000000080000000) larger than  32 bits kbuild test robot <fengguang.wu@intel.com> - 2016-04-17 02:30 +0200
    Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits Ralf Baechle <ralf@linux-mips.org> - 2016-04-17 03:20 +0200
      Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits "Maciej W. Rozycki" <macro@linux-mips.org> - 2016-04-17 16:50 +0200
        Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits Ralf Baechle <ralf@linux-mips.org> - 2016-04-18 15:40 +0200
          Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits "Maciej W. Rozycki" <macro@imgtec.com> - 2016-04-18 16:30 +0200
            Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits Ralf Baechle <ralf@linux-mips.org> - 2016-04-18 18:00 +0200
              Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits "Maciej W. Rozycki" <macro@imgtec.com> - 2016-04-18 20:20 +0200
                Re: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits "Maciej W. Rozycki" <macro@imgtec.com> - 2016-04-19 02:30 +0200
                  RE: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits Matthew Fortune <Matthew.Fortune@imgtec.com> - 2016-04-19 16:50 +0200
                    RE: {standard input}:136: Error: number (0x9000000080000000) larger  than 32 bits "Maciej W. Rozycki" <macro@imgtec.com> - 2016-04-22 03:10 +0200

#1380663 — {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

Fromkbuild test robot <fengguang.wu@intel.com>
Date2016-04-17 02:30 +0200
Subject{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<roIL8-3F5-11@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   306a63bee192859ebd32c7328c7766636d882d8f
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   10 months ago
config: mips-jz4740 (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   {standard input}: Assembler messages:
>> {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
   {standard input}:161: Error: number (0x9000000080000000) larger than 32 bits

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[toc] | [next] | [standalone]

#1380676 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

FromRalf Baechle <ralf@linux-mips.org>
Date2016-04-17 03:20 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<roJxw-4hm-3@gated-at.bofh.it>
In reply to#1380663
On Sun, Apr 17, 2016 at 08:20:38AM +0800, kbuild test robot wrote:

> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   306a63bee192859ebd32c7328c7766636d882d8f
> commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
> date:   10 months ago
> config: mips-jz4740 (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout de361e8bb9f666235d44ae9770238718be4f0483
>         # save the attached .config to linux build tree
>         make.cross ARCH=mips 
> 
> All errors (new ones prefixed by >>):
> 
>    {standard input}: Assembler messages:
> >> {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
>    {standard input}:161: Error: number (0x9000000080000000) larger than 32 bits

This is a toolchain issue afaik which I believe is the same I was seeing
a while ago on Imaginations buildbot.  There it has gone away presumably
after a toolchain upgrade.  Maciej, do you recall which versions were
affected?

  Ralf

[toc] | [prev] | [next] | [standalone]

#1380763 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

From"Maciej W. Rozycki" <macro@linux-mips.org>
Date2016-04-17 16:50 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<roWbn-5VG-5@gated-at.bofh.it>
In reply to#1380676
Ralf,

> > All errors (new ones prefixed by >>):
> > 
> >    {standard input}: Assembler messages:
> > >> {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
> >    {standard input}:161: Error: number (0x9000000080000000) larger than 32 bits
> 
> This is a toolchain issue afaik which I believe is the same I was seeing
> a while ago on Imaginations buildbot.  There it has gone away presumably
> after a toolchain upgrade.  Maciej, do you recall which versions were
> affected?

 I've been wondering about these errors too as I have never come across 
them myself.  So I have no idea what's causing them and I can't really 
help other than maybe running `git bisect' on binutils sometime.  Or is 
there a way to get the version of GAS involved? -- `as --version' will do.  
I could see if I could build it and reproduce the problem to see what's 
causing it.  Also seeing the offending .s file could help too, i.e. 
knowing what the context is here.

  Maciej

[toc] | [prev] | [next] | [standalone]

#1381702 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

FromRalf Baechle <ralf@linux-mips.org>
Date2016-04-18 15:40 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rphzc-6pz-5@gated-at.bofh.it>
In reply to#1380763
On Sun, Apr 17, 2016 at 03:43:49PM +0100, Maciej W. Rozycki wrote:

> > > All errors (new ones prefixed by >>):
> > > 
> > >    {standard input}: Assembler messages:
> > > >> {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
> > >    {standard input}:161: Error: number (0x9000000080000000) larger than 32 bits
> > 
> > This is a toolchain issue afaik which I believe is the same I was seeing
> > a while ago on Imaginations buildbot.  There it has gone away presumably
> > after a toolchain upgrade.  Maciej, do you recall which versions were
> > affected?
> 
>  I've been wondering about these errors too as I have never come across 
> them myself.  So I have no idea what's causing them and I can't really 
> help other than maybe running `git bisect' on binutils sometime.  Or is 
> there a way to get the version of GAS involved? -- `as --version' will do.  
> I could see if I could build it and reproduce the problem to see what's 
> causing it.  Also seeing the offending .s file could help too, i.e. 
> knowing what the context is here.

I tried to reproduce the issue with stock FSF GCC 5.2.0 and binutils 2.24,
2.25 and 2.26 and the commit ID and .config from this thread, no luck.

The old case btw, affects ip22 with a random_config:

  CC      arch/mips/mm/sc-ip22.o
{standard input}: Assembler messages:
{standard input}:137: Error: number (0x9000000080000000) larger than 32 bits
{standard input}:162: Error: number (0x9000000080000000) larger than 32 bits
scripts/Makefile.build:258: recipe for target 'arch/mips/mm/sc-ip22.o' failed
make[2]: *** [arch/mips/mm/sc-ip22.o] Error 1
scripts/Makefile.build:403: recipe for target 'arch/mips/mm' failed
make[1]: *** [arch/mips/mm] Error 2
Makefile:947: recipe for target 'arch/mips' failed
make: *** [arch/mips] Error 2

and I was able to reproduce it with binutils 2.26 and commit
c517d838eb7d07bbe9507871fab3931deccff539 ("Linux 4.0-rc1").  The code
in question looks like:

static inline void indy_sc_wipe(unsigned long first, unsigned long last)
{
        unsigned long tmp;

        __asm__ __volatile__(
        ".set\tpush\t\t\t# indy_sc_wipe\n\t"
        ".set\tnoreorder\n\t"
        ".set\tmips3\n\t"
        ".set\tnoat\n\t"
        "mfc0\t%2, $12\n\t"
        "li\t$1, 0x80\t\t\t# Go 64 bit\n\t"
        "mtc0\t$1, $12\n\t"

        "dli\t$1, 0x9000000080000000\n\t"
[...]

The same commit, same toolchain with ip22_defconfig builds just fine.
Seems the difference is CONFIG_CPU_R4X00 vs. CONFIG_CPU_R5000.  Not
sure why that would make a difference.

  Ralf

[toc] | [prev] | [next] | [standalone]

#1381751 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

From"Maciej W. Rozycki" <macro@imgtec.com>
Date2016-04-18 16:30 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rpilz-75e-7@gated-at.bofh.it>
In reply to#1381702
On Mon, 18 Apr 2016, Ralf Baechle wrote:

> The old case btw, affects ip22 with a random_config:
> 
>   CC      arch/mips/mm/sc-ip22.o
> {standard input}: Assembler messages:
> {standard input}:137: Error: number (0x9000000080000000) larger than 32 bits
> {standard input}:162: Error: number (0x9000000080000000) larger than 32 bits
> scripts/Makefile.build:258: recipe for target 'arch/mips/mm/sc-ip22.o' failed
> make[2]: *** [arch/mips/mm/sc-ip22.o] Error 1
> scripts/Makefile.build:403: recipe for target 'arch/mips/mm' failed
> make[1]: *** [arch/mips/mm] Error 2
> Makefile:947: recipe for target 'arch/mips' failed
> make: *** [arch/mips] Error 2
> 
> and I was able to reproduce it with binutils 2.26 and commit
> c517d838eb7d07bbe9507871fab3931deccff539 ("Linux 4.0-rc1").  The code
> in question looks like:
> 
> static inline void indy_sc_wipe(unsigned long first, unsigned long last)
> {
>         unsigned long tmp;
> 
>         __asm__ __volatile__(
>         ".set\tpush\t\t\t# indy_sc_wipe\n\t"
>         ".set\tnoreorder\n\t"
>         ".set\tmips3\n\t"
>         ".set\tnoat\n\t"
>         "mfc0\t%2, $12\n\t"
>         "li\t$1, 0x80\t\t\t# Go 64 bit\n\t"
>         "mtc0\t$1, $12\n\t"
> 
>         "dli\t$1, 0x9000000080000000\n\t"

 That does not help me, I'm afraid, I can't trigger the issue with this 
piece of code alone.  It may be caused by a particular combination of GAS
command line options and `.set' directives.

 Since you can reproduce it, can you please send me the offending .s file 
(`make arch/mips/mm/sc-ip22.s') and the GAS invocation line used?  GCC 
will print the latter along all kinds of diagnostic stuff if -v is passed 
to an invocation involving assembly (e.g. `make V=1 CFLAGS_sc-ip22.o=-v 
arch/mips/mm/sc-ip22.o').  You can send me the whole diagnostics, I'll 
filter what I need.

 I think it'll be the most efficient way to move forward; otherwise I may 
keep missing the issue.

 Thanks,

  Maciej

[toc] | [prev] | [next] | [standalone]

#1381851 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

FromRalf Baechle <ralf@linux-mips.org>
Date2016-04-18 18:00 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rpjKH-82N-17@gated-at.bofh.it>
In reply to#1381751
On Mon, Apr 18, 2016 at 03:25:56PM +0100, Maciej W. Rozycki wrote:

> On Mon, 18 Apr 2016, Ralf Baechle wrote:
> 
> > The old case btw, affects ip22 with a random_config:
> > 
> >   CC      arch/mips/mm/sc-ip22.o
> > {standard input}: Assembler messages:
> > {standard input}:137: Error: number (0x9000000080000000) larger than 32 bits
> > {standard input}:162: Error: number (0x9000000080000000) larger than 32 bits
> > scripts/Makefile.build:258: recipe for target 'arch/mips/mm/sc-ip22.o' failed
> > make[2]: *** [arch/mips/mm/sc-ip22.o] Error 1
> > scripts/Makefile.build:403: recipe for target 'arch/mips/mm' failed
> > make[1]: *** [arch/mips/mm] Error 2
> > Makefile:947: recipe for target 'arch/mips' failed
> > make: *** [arch/mips] Error 2
> > 
> > and I was able to reproduce it with binutils 2.26 and commit
> > c517d838eb7d07bbe9507871fab3931deccff539 ("Linux 4.0-rc1").  The code
> > in question looks like:
> > 
> > static inline void indy_sc_wipe(unsigned long first, unsigned long last)
> > {
> >         unsigned long tmp;
> > 
> >         __asm__ __volatile__(
> >         ".set\tpush\t\t\t# indy_sc_wipe\n\t"
> >         ".set\tnoreorder\n\t"
> >         ".set\tmips3\n\t"
> >         ".set\tnoat\n\t"
> >         "mfc0\t%2, $12\n\t"
> >         "li\t$1, 0x80\t\t\t# Go 64 bit\n\t"
> >         "mtc0\t$1, $12\n\t"
> > 
> >         "dli\t$1, 0x9000000080000000\n\t"
> 
>  That does not help me, I'm afraid, I can't trigger the issue with this 
> piece of code alone.  It may be caused by a particular combination of GAS
> command line options and `.set' directives.
> 
>  Since you can reproduce it, can you please send me the offending .s file 
> (`make arch/mips/mm/sc-ip22.s') and the GAS invocation line used?  GCC 
> will print the latter along all kinds of diagnostic stuff if -v is passed 
> to an invocation involving assembly (e.g. `make V=1 CFLAGS_sc-ip22.o=-v 
> arch/mips/mm/sc-ip22.o').  You can send me the whole diagnostics, I'll 
> filter what I need.
> 
>  I think it'll be the most efficient way to move forward; otherwise I may 
> keep missing the issue.

I extracted a rather simple test case:

$ echo >> testcase .s << EOF
        .set    mips3
        dli     $2, 0x9000000080000000
EOF
$ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s
testcase.s: Assembler messages:
testcase.s:2: Error: number (0x9000000080000000) larger than 32 bits
$ mips-linux-as -mips4 -march=vr5000 -o testcase.o testcase.s
$

I can trigger the error message with vanilla 2.25 and 2.26 but not 2.24.

  Ralf

[toc] | [prev] | [next] | [standalone]

#1381955 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

From"Maciej W. Rozycki" <macro@imgtec.com>
Date2016-04-18 20:20 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rplWa-1vv-3@gated-at.bofh.it>
In reply to#1381851
On Mon, 18 Apr 2016, Ralf Baechle wrote:

> I extracted a rather simple test case:
> 
> $ echo >> testcase .s << EOF
>         .set    mips3
>         dli     $2, 0x9000000080000000
> EOF
> $ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s
> testcase.s: Assembler messages:
> testcase.s:2: Error: number (0x9000000080000000) larger than 32 bits
> $ mips-linux-as -mips4 -march=vr5000 -o testcase.o testcase.s
> $

 Ah, and if you use `.set mips4' instead, then the symptoms reverse.

 The thing is that to match some software's (such as ours) requirements an 
ISA override -- as a side effect -- relaxes ABI restrictions on certain 
operations.  E.g. the DLI macro and its 64-bit immediate argument are not 
valid in the o32 ABI.  When no actual override happens, such as with 
`-march=r4600' which already implies `mips3' for the ISA, the side effect 
is lost:

  /* The use of .set [arch|cpu]= historically 'fixes' the width of gp and fp
     registers based on what is supported by the arch/cpu.  */
  if (mips_opts.isa != prev_isa)

> I can trigger the error message with vanilla 2.25 and 2.26 but not 2.24.

 The regression has come with:

commit 919731affbef19fcad8dddb0a595bb05755cb345
Author: mfortune <matthew.fortune@imgtec.com>
Date:   Tue May 20 13:28:20 2014 +0100

    Add MIPS .module directive

-- previously the side effect was unconditional, even if no ISA change 
resulted.

 Matthew, this functional change was not mentioned in the review: 
<https://sourceware.org/ml/binutils/2014-05/msg00179.html> -- what was the 
rationale behind it?  Do you expect any issues if we revert to old 
semantics?

  Maciej

[toc] | [prev] | [next] | [standalone]

#1382113 — Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

From"Maciej W. Rozycki" <macro@imgtec.com>
Date2016-04-19 02:30 +0200
SubjectRe: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rprIe-6oT-19@gated-at.bofh.it>
In reply to#1381955
On Mon, 18 Apr 2016, Maciej W. Rozycki wrote:

>  The thing is that to match some software's (such as ours) requirements an 
> ISA override -- as a side effect -- relaxes ABI restrictions on certain 
> operations.  E.g. the DLI macro and its 64-bit immediate argument are not 
> valid in the o32 ABI.  When no actual override happens, such as with 
> `-march=r4600' which already implies `mips3' for the ISA, the side effect 
> is lost:
> 
>   /* The use of .set [arch|cpu]= historically 'fixes' the width of gp and fp
>      registers based on what is supported by the arch/cpu.  */
>   if (mips_opts.isa != prev_isa)

 It's worse yet actually, as operations such as `.set pop' and `.set 
mips0' may not restore the ABI restrictions, possibly leading to wrong 
code generation elsewhere, generally in handcoded assembly only.  This can 
be illustrated with a program like:

	.set	push
	.set	mips3
	dli	$2, 0x9000000080000000
	.set	mips0
	dli	$2, 0x9000000080000000
	.set	mips3
	.set	pop
	dli	$2, 0x9000000080000000

-- try building it with `-mips3' and `-mips4' to see how it fails or 
succeeds to assemble all the three DLI macros respectively, where it is 
supposed to succeed with the first macro only and fail with the other two 
in both cases.

 I have a fix in the works and to have it integrated upstream I just need 
to accompany it with suitable cases -- like the fragment above -- for the 
GAS testsuite.  I'll send an update when it's ready.

  Maciej

[toc] | [prev] | [next] | [standalone]

#1382585 — RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

FromMatthew Fortune <Matthew.Fortune@imgtec.com>
Date2016-04-19 16:50 +0200
SubjectRE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rpF8u-8oB-13@gated-at.bofh.it>
In reply to#1382113
Maciej Rozycki <Maciej.Rozycki@imgtec.com> writes:
> On Mon, 18 Apr 2016, Maciej W. Rozycki wrote:
> 
> >  The thing is that to match some software's (such as ours)
> > requirements an ISA override -- as a side effect -- relaxes ABI
> > restrictions on certain operations.  E.g. the DLI macro and its 64-bit
> > immediate argument are not valid in the o32 ABI.  When no actual
> > override happens, such as with `-march=r4600' which already implies
> > `mips3' for the ISA, the side effect is lost:
> >
> >   /* The use of .set [arch|cpu]= historically 'fixes' the width of gp
> and fp
> >      registers based on what is supported by the arch/cpu.  */
> >   if (mips_opts.isa != prev_isa)
> 
>  It's worse yet actually, as operations such as `.set pop' and `.set
> mips0' may not restore the ABI restrictions, possibly leading to wrong
> code generation elsewhere, generally in handcoded assembly only.  This
> can be illustrated with a program like:
> 
> 	.set	push
> 	.set	mips3
> 	dli	$2, 0x9000000080000000
> 	.set	mips0
> 	dli	$2, 0x9000000080000000
> 	.set	mips3
> 	.set	pop
> 	dli	$2, 0x9000000080000000
> 
> -- try building it with `-mips3' and `-mips4' to see how it fails or
> succeeds to assemble all the three DLI macros respectively, where it is
> supposed to succeed with the first macro only and fail with the other
> two in both cases.
> 
>  I have a fix in the works and to have it integrated upstream I just
> need to accompany it with suitable cases -- like the fragment above --
> for the GAS testsuite.  I'll send an update when it's ready.

I do not think the change in behaviour was intentional. I think it came
about because I separated the handling of an explicit .set mips* directive
from the implicit setting of gp/fp. I needed to ensure that gp/fp was
only updated when there was a .set mips* directive but missed the case
where you have an explicit directive that matches the current mips*
setting.

The conditional nature of updating 'fp' is however very much intentional
in that if a user enters 'fpxx' mode where fp==0 then the implicit update
of fp does not happen. This is OK as this behaviour only triggers when
using the newly added fpxx feature anyway.

I am generally not in favour of these implicit side-effect behaviours
as they are only useful in niche cases and are somewhat non-intuitive but
we are stuck with them because of history. It would be possible to write
code that does not need them by explicitly using the .set gp or .set fp
options. There is little we can do about that given historic precedent
though. Instead code that does not want the implicit behaviour has to
explicitly do things like:

.set mips3
.set gp=default
.set fp=default

Matthew

[toc] | [prev] | [next] | [standalone]

#1384656 — RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

From"Maciej W. Rozycki" <macro@imgtec.com>
Date2016-04-22 03:10 +0200
SubjectRE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Message-ID<rqxLA-1Lo-7@gated-at.bofh.it>
In reply to#1382585
On Tue, 19 Apr 2016, Matthew Fortune wrote:

> >  I have a fix in the works and to have it integrated upstream I just
> > need to accompany it with suitable cases -- like the fragment above --
> > for the GAS testsuite.  I'll send an update when it's ready.
> 
> I do not think the change in behaviour was intentional. I think it came
> about because I separated the handling of an explicit .set mips* directive
> from the implicit setting of gp/fp. I needed to ensure that gp/fp was
> only updated when there was a .set mips* directive but missed the case
> where you have an explicit directive that matches the current mips*
> setting.

 I had thought it might have been intentional before I realised the 
problem also affected ISA restoration, at which point I concluded it had 
been simply an oversight.

 While looking at it I've noticed we support somewhat questionable 
settings with the related `.module' directive, such as:

	.module	at=$k0
	.module	nomove

They have no command-line counterparts, so there's really no difference 
between having a `.module' or a corresponding `.set' directive at the top 
of a source file.  There's no `.module' support for the similar `nomacro' 
or `noreorder' settings though.  Was there a hidden motivation that you 
had to make such an arrangement?

> The conditional nature of updating 'fp' is however very much intentional
> in that if a user enters 'fpxx' mode where fp==0 then the implicit update
> of fp does not happen. This is OK as this behaviour only triggers when
> using the newly added fpxx feature anyway.

 Sure, my only concern has been the inconsistency between the case where 
the ISA is actually switched and one where it remains the same after a 
`.set' pseudo-op.

> I am generally not in favour of these implicit side-effect behaviours
> as they are only useful in niche cases and are somewhat non-intuitive but
> we are stuck with them because of history. It would be possible to write
> code that does not need them by explicitly using the .set gp or .set fp
> options. There is little we can do about that given historic precedent
> though. Instead code that does not want the implicit behaviour has to
> explicitly do things like:
> 
> .set mips3
> .set gp=default
> .set fp=default

 Well, historically we had very little control and old code adapted to it.  
Even the `.set gp=' and `.set fp=' directives are relatively recent in the 
history of the MIPS port.  So I agree -- had we had control we have today 
back when the MIPS port started, this would have been better handled with 
these more finegrained knobs.  Before NewABI support was added even using 
e.g. `-mips3' on the command line made full 64-bit registers available.

 I have fixed the bug upstream now:

commit 22522f880a8e17a17c4f195796ec89caece7652b
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Apr 22 01:04:52 2016 +0100

    MIPS/GAS: Fix an ISA override not lifting ABI restrictions

and included suitable test cases with the fix.  The lack of testsuite 
coverage here is what let this bug remain unnoticed.

  Maciej

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web