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]

Date:	Tue, 19 Apr 2016 01:25:38 +0100
From:	"Maciej W. Rozycki" <macro@...tec.com>
To:	Ralf Baechle <ralf@...ux-mips.org>,
	Matthew Fortune <Matthew.Fortune@...tec.com>
CC:	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	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 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