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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160418133449.GB24051@linux-mips.org>
Date:	Mon, 18 Apr 2016 15:34:49 +0200
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	kbuild test robot <fengguang.wu@...el.com>,
	Paul Burton <paul.burton@...tec.com>, kbuild-all@...org,
	linux-kernel@...r.kernel.org
Subject: Re: {standard input}:136: Error: number (0x9000000080000000) larger
 than 32 bits

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