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
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
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
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
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
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
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 <[email protected]>
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
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
Maciej Rozycki <[email protected]> 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
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 <[email protected]>
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