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


Groups > linux.kernel > #1381955

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

From "Maciej W. Rozycki" <macro@imgtec.com>
Newsgroups linux.kernel
Subject Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Date 2016-04-18 20:20 +0200
Message-ID <rplWa-1vv-3@gated-at.bofh.it> (permalink)
References (1 earlier) <roJxw-4hm-3@gated-at.bofh.it> <roWbn-5VG-5@gated-at.bofh.it> <rphzc-6pz-5@gated-at.bofh.it> <rpilz-75e-7@gated-at.bofh.it> <rpjKH-82N-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

{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

csiph-web