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: <6D39441BF12EF246A7ABCE6654B023537E3DB822@hhmail02.hh.imgtec.org>
Date:	Tue, 19 Apr 2016 14:43:45 +0000
From:	Matthew Fortune <Matthew.Fortune@...tec.com>
To:	Maciej Rozycki <Maciej.Rozycki@...tec.com>,
	Ralf Baechle <ralf@...ux-mips.org>
CC:	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	kbuild test robot <fengguang.wu@...el.com>,
	Paul Burton <Paul.Burton@...tec.com>,
	"kbuild-all@...org" <kbuild-all@...org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: {standard input}:136: Error: number (0x9000000080000000) larger
 than 32 bits

Maciej Rozycki <Maciej.Rozycki@...tec.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