Can't compile longson kernels

[Martin Husemann]

Hey folks,

the bulk builds for evbmips64 have been failing since a long time.
Problem is: the compiler generates code like:

ld $31,24($sp)
ld $16,16($sp)
$LVL2 = .
j $31
daddiu $sp,$sp,32

and "j" is a macro, expanding to multiple instructions in this case, which
causes a warning. The assembler is invoked with -mips3,
or to be precise:

tools/lib/gcc/mips64el--netbsd/4.5.4/../../../../mips64el--netbsd/bin/as -G 0 -EL -mips3 -O2 -g -no-mdebug -mabi=64 -msym32 -v -mfix-loongson2f-btb --fatal-warnings -o compat_util.o

I somehow thought load delay slots would be mips1 only?

Is the warning bogus? Am I missing something?

Martin

[Manuel Bouyer]

Post by Martin Husemann
Hey folks,
the bulk builds for evbmips64 have been failing since a long time.
ld $31,24($sp)
ld $16,16($sp)
$LVL2 = .
j $31
daddiu $sp,$sp,32
and "j" is a macro, expanding to multiple instructions in this case, which
causes a warning. The assembler is invoked with -mips3,
tools/lib/gcc/mips64el--netbsd/4.5.4/../../../../mips64el--netbsd/bin/as -G 0 -EL -mips3 -O2 -g -no-mdebug -mabi=64 -msym32 -v -mfix-loongson2f-btb --fatal-warnings -o compat_util.o
I somehow thought load delay slots would be mips1 only?

i'm not sure about this. In fact, I'm almost sure mips32r2 still has them.

Post by Martin Husemann
Is the warning bogus? Am I missing something?

I don't understand why j would expand to a macro in this case.
It should just be a jr (jump register). Or maybe the compiler is wrong and
should generate a jr and not a plain j.

[Manuel Bouyer]

Post by Manuel Bouyer

Post by Martin Husemann
Hey folks,
the bulk builds for evbmips64 have been failing since a long time.
ld $31,24($sp)
ld $16,16($sp)
$LVL2 = .
j $31
daddiu $sp,$sp,32
and "j" is a macro, expanding to multiple instructions in this case, which
causes a warning. The assembler is invoked with -mips3,
tools/lib/gcc/mips64el--netbsd/4.5.4/../../../../mips64el--netbsd/bin/as -G 0 -EL -mips3 -O2 -g -no-mdebug -mabi=64 -msym32 -v -mfix-loongson2f-btb --fatal-warnings -o compat_util.o
I somehow thought load delay slots would be mips1 only?

i'm not sure about this. In fact, I'm almost sure mips32r2 still has them.

Post by Martin Husemann
Is the warning bogus? Am I missing something?

I don't understand why j would expand to a macro in this case.
It should just be a jr (jump register). Or maybe the compiler is wrong and
should generate a jr and not a plain j.

The problem seems to be -Wa,-mfix-loongson2f-jump.
The jump will indeed expand to multiple instructions. But it's also supposed
to not cause a warning (it's harmless in this case because the jump will
still be at the end of the exanded macro), see gas/config/tc-mips.c.
I wonder is something changed here, that cause the warning workaround to
not work any more (-Wa,-mfix-loongson2f-jump is from upstream, but
this warning workaround is a local change).

[Martin Husemann]

Post by Manuel Bouyer
I wonder is something changed here, that cause the warning workaround to
not work any more (-Wa,-mfix-loongson2f-jump is from upstream, but
this warning workaround is a local change).

I think this is broken since the binutils update.

Martin

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
I wonder is something changed here, that cause the warning workaround to
not work any more (-Wa,-mfix-loongson2f-jump is from upstream, but
this warning workaround is a local change).

I think this is broken since the binutils update.

Right. The attached patch should make our local hack work with the new
binutils. I can't test a LOOGSON kernel right now, unfortunably ...

[Martin Husemann]

Post by Manuel Bouyer
Right. The attached patch should make our local hack work with the new
binutils. I can't test a LOOGSON kernel right now, unfortunably ...

Me neither (can only build test).
Could you commit and file a ticket upstream?

Martin

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
Right. The attached patch should make our local hack work with the new
binutils. I can't test a LOOGSON kernel right now, unfortunably ...

Me neither (can only build test).
Could you commit and file a ticket upstream?

commited, but I don't think an upstream ticket is appropriate:
this is a local patch, nothing is broken upstream.
I don't think this hack would be accepted upstream either ...

[Martin Husemann]

Post by Manuel Bouyer
this is a local patch, nothing is broken upstream.
I don't think this hack would be accepted upstream either ...

I don't get it - either the warning is bogus and the fix is appropriate
for an upstream ticket, or we need to look deeper for the real error.


Martin

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
this is a local patch, nothing is broken upstream.
I don't think this hack would be accepted upstream either ...

I don't get it - either the warning is bogus and the fix is appropriate
for an upstream ticket, or we need to look deeper for the real error.

The warning is not bogus, and there's no real error either.
The loongson jump fix does really replace a jump instruction with
multiple instructions that ends with a jump. This hack in our local source
is because we (NetBSD) don't want the warning in this specific case
(but we do want it if other macros cause one instruction to
be remplaced by multiple instructions). The alternatives are to
remove -mfix-loongson2f-jump (but then the hardware may hang) or
remove --fatal-warnings (but then we don't get errors when other
macros may cause real issues).

[Martin Husemann]

Post by Manuel Bouyer
The warning is not bogus, and there's no real error either.
The loongson jump fix does really replace a jump instruction with
multiple instructions that ends with a jump. This hack in our local source
is because we (NetBSD) don't want the warning in this specific case
(but we do want it if other macros cause one instruction to
be remplaced by multiple instructions). The alternatives are to
remove -mfix-loongson2f-jump (but then the hardware may hang) or
remove --fatal-warnings (but then we don't get errors when other
macros may cause real issues).

Yes, of course. And that all is why this is a valid fix and appropriate
for upstream inclusion, IMHO.

To cite from info gas:

`as' should never give a warning or error message when assembling
compiler output.


But in this case, it does.


Martin

[Matt Thomas]

Post by Martin Husemann

Post by Manuel Bouyer
The warning is not bogus, and there's no real error either.
The loongson jump fix does really replace a jump instruction with
multiple instructions that ends with a jump. This hack in our local source
is because we (NetBSD) don't want the warning in this specific case
(but we do want it if other macros cause one instruction to
be remplaced by multiple instructions). The alternatives are to
remove -mfix-loongson2f-jump (but then the hardware may hang) or
remove --fatal-warnings (but then we don't get errors when other
macros may cause real issues).

Yes, of course. And that all is why this is a valid fix and appropriate
for upstream inclusion, IMHO.
`as' should never give a warning or error message when assembling
compiler output.
But in this case, it does.

he compiler should have emitted .set nomacro so
j foo
should never be expanded as a macro.

[Martin Husemann]

Post by Matt Thomas
he compiler should have emitted .set nomacro so
j foo
should never be expanded as a macro.

FWIW, gcc 4.8.2 generates the same code (and produces the warning with
stock binutils). Can you poke the right upstream people, please?

Martin

[Martin Husemann]

The changes as commited fixed the build for me, but now it came back on the
latest autobuild:

http://releng.netbsd.org/builds/HEAD/201312050420Z/evbmips-mips64el.build.failed


Martin

[Manuel Bouyer]

Post by Martin Husemann
The changes as commited fixed the build for me, but now it came back on the
http://releng.netbsd.org/builds/HEAD/201312050420Z/evbmips-mips64el.build.failed

there was an error in my previous commit. GDIUM64 kernel did build,
but not LOONGSON. hopefully it's fixed now.