[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[ma...@linux-mips.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

--- Comment #6 from Maciej W. Rozycki  ---
Fixed in binutils now:

commit 65060a78866f374e25f4668d12efc783235d19d1
Author: Maciej W. Rozycki 
Date:   Wed Jan 18 18:18:21 2017 +

PR gas/20649: MIPS: Fix GOT16/LO16 reloc pairing with comdat sections

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[aurelien at aurel32 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #1 from Aurelien Jarno  ---
I have tried to identified when this behavior has been introduced. It appears
that even GCC 4.9 is producing similar code. However what cause ld to reject it
is the following change in the assembly code:

-   .text
+   .section   
.text._ZN1HIiE5m_fn4ERK1G.isra.1,"axG",@progbits,_ZN1HIiE5m_fn5ERK1G,comdat

It seems the optimization is somehow correct when all the code is in the same
section, but that's no the case anymore when it is in multiple sections.

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[ma...@linux-mips.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org

--- Comment #2 from Maciej W. Rozycki  ---
Thank you for your bug report.

The SVR4 MIPS psABI (o32) mandates that a HI16 or a local GOT16
relocation is immediately followed by a matching LO16 relocation.  To
address the very scenario described here however as a GNU extension we
support an arbitrary number of HI16 or GOT16 relocations followed by a
matching LO16 relocation.  This is explicitly noted in BFD sources:

  "The ABI requires that the *LO16 immediately follow the *HI16.
   However, as a GNU extension, we permit an arbitrary number of
   *HI16s to be associated with a single *LO16.  This significantly
   simplies the relocation handling in gcc."

and has been like this since forever.  The pairing is supposed to be
done by the assembler so as long it has been done correctly there's
nothing for the linker to complain about.

I see in the Debian bug report referred that this error only happens
with `gold', so I am highly suspicious that this is a `gold' bug.  To
ensure all is in order would you therefore please send me the output of
`readelf -r src.o' and double-check your results with both `ld' and
`gold'?

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[james410 at cowgill dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

--- Comment #3 from James Cowgill  ---
$ mipsel-linux-gnu-readelf -r src.o

Relocation section '.rel.text' at offset 0x584 contains 6 entries:
 Offset InfoTypeSym.Value  Sym. Name
  1005 R_MIPS_HI16      _gp_disp
0004  1006 R_MIPS_LO16      _gp_disp
0010  170b R_MIPS_CALL16    _ZN1GC1Ei
0028  1725 R_MIPS_JALR      _ZN1GC1Ei
0038  130b R_MIPS_CALL16    _ZN1HIiE5m_fn5ERK1G
003c  1325 R_MIPS_JALR      _ZN1HIiE5m_fn5ERK1G

Relocation section '.rel.pdr' at offset 0x5b4 contains 3 entries:
 Offset InfoTypeSym.Value  Sym. Name
  0702 R_MIPS_32    _ZN1HIiE5m_fn4ERK1G.is
0020  1302 R_MIPS_32    _ZN1HIiE5m_fn5ERK1G
0040  1802 R_MIPS_32    _Z3fn1v

Relocation section '.rel.text._ZN1HIiE5m_fn4ERK1G.isra.1' at offset 0x5cc
contains 6 entries:
 Offset InfoTypeSym.Value  Sym. Name
  1005 R_MIPS_HI16      _gp_disp
0004  1006 R_MIPS_LO16      _gp_disp
0010  110b R_MIPS_CALL16    _ZN1DC1EP1C
0030  1125 R_MIPS_JALR      _ZN1DC1EP1C
0044  120b R_MIPS_CALL16    _ZN1HIiE5m_fn3EP1C
0048  1225 R_MIPS_JALR      _ZN1HIiE5m_fn3EP1C

Relocation section '.rel.text._ZN1HIiE5m_fn5ERK1G' at offset 0x5fc contains 18
entries:
 Offset InfoTypeSym.Value  Sym. Name
  1005 R_MIPS_HI16      _gp_disp
0004  1006 R_MIPS_LO16      _gp_disp
0010  140b R_MIPS_CALL16    _ZN1HIiE5m_fn2Ev
0028  1425 R_MIPS_JALR      _ZN1HIiE5m_fn2Ev
0038  150b R_MIPS_CALL16    _ZN1HIiE5m_fn1Ev
003c  1525 R_MIPS_JALR      _ZN1HIiE5m_fn1Ev
0048  160b R_MIPS_CALL16    _ZN1HIiE5m_fn6Ev
004c  1625 R_MIPS_JALR      _ZN1HIiE5m_fn6Ev
005c  0709 R_MIPS_GOT16     _ZN1HIiE5m_fn4ERK1G.is
0060  0706 R_MIPS_LO16      _ZN1HIiE5m_fn4ERK1G.is
0068  0725 R_MIPS_JALR      _ZN1HIiE5m_fn4ERK1G.is
0074  0725 R_MIPS_JALR      _ZN1HIiE5m_fn4ERK1G.is
0094  170b R_MIPS_CALL16    _ZN1GC1Ei
009c  1725 R_MIPS_JALR      _ZN1GC1Ei
00b0  150b R_MIPS_CALL16    _ZN1HIiE5m_fn1Ev
00b4  1525 R_MIPS_JALR      _ZN1HIiE5m_fn1Ev
00cc  0709 R_MIPS_GOT16     _ZN1HIiE5m_fn4ERK1G.is
00d4  150b R_MIPS_CALL16    _ZN1HIiE5m_fn1Ev

Relocation section '.rel.eh_frame' at offset 0x68c contains 3 entries:
 Offset InfoTypeSym.Value  Sym. Name
001c  0602 R_MIPS_32    .text._ZN1HIiE5m_fn4ER
0054  0802 R_MIPS_32    .text._ZN1HIiE5m_fn5ER
0090  0202 R_MIPS_32    .text

$ mipsel-linux-gnu-gcc -fuse-ld=bfd src.o
[... omitted irrelevant undefined references]
/usr/lib/gcc-cross/mipsel-linux-gnu/6/../../../../mipsel-linux-gnu/bin/ld.bfd:
src.o: Can't find matching LO16 reloc against `_ZN1HIiE5m_fn4ERK1G.isra.1' for
R_MIPS_GOT16 at 0xcc in section
`.text._ZN1HIiE5m_fn5ERK1G[_ZN1HIiE5m_fn5ERK1G]'
[...]

$ mipsel-linux-gnu-gcc -fuse-ld=gold src.o 
/usr/lib/gcc-cross/mipsel-linux-gnu/6/../../../../mipsel-linux-gnu/bin/ld.gold:
error: Can't find matching LO16 reloc
/usr/lib/gcc-cross/mipsel-linux-gnu/6/../../../../mipsel-linux-gnu/bin/ld.gold:
error: Can't find matching LO16 reloc
/usr/lib/gcc-cross/mipsel-linux-gnu/6/../../../../mipsel-linux-gnu/bin/ld.gold:
error: Can't find matching LO16 reloc
/usr/lib/gcc-cross/mipsel-linux-gnu/6/../../../../mipsel-linux-gnu/bin/ld.gold:
error: Can't find matching LO16 reloc
[...]

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[ma...@linux-mips.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

--- Comment #4 from Maciej W. Rozycki  ---
Thanks.  I didn't expect -W would be required for non-truncated output,
however at this stage it looks anyway like it's GAS which is at fault,
because the GOT16 relocation at 0xcc isn't reordered (in the relocation
table) ahead the LO16 relocation at 0x60.

Could you therefore please file a bug against GAS at
 and attach the generated assembly
which has triggered this problem?  I'll take it from there.

This bug can now be closed although I can't seem able to do that for
some reason.  NB it would be good to have links both ways recorded
between the bug entries, so please record a link here once you've got
the other bug's ID.

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[james410 at cowgill dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

James Cowgill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #5 from James Cowgill  ---
Moved here:
https://sourceware.org/bugzilla/show_bug.cgi?id=20649

It seems I can close the bug so doing it now.