maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/mips-xgot-order.s

50 lines
1.6 KiB
ArmAsm
Raw Normal View History

[ELF] Move `# REQUIRES:` line to the top llvm-svn: 335625
2018-06-27 00:58:19 +08:00
# REQUIRES: mips
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
# Check that GOT entries accessed via 16-bit indexing are allocated
# in the beginning of the GOT.
# RUN: llvm-mc -filetype=obj -triple=mips-unknown-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t.exe
# RUN: llvm-objdump -d -s -t %t.exe | FileCheck %s
# CHECK: Disassembly of section .text:
[llvm-objdump] Print newlines before and after "Disassembly of section ...:" This improves readability and the behavior is consistent with GNU objdump. The new test test/tools/llvm-objdump/X86/disassemble-section-name.s checks we print newlines before and after "Disassembly of section ...:" Differential Revision: https://reviews.llvm.org/D61127 llvm-svn: 359668
2019-05-01 18:40:48 +08:00
# CHECK-EMPTY:
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
# CHECK-NEXT: __start:
# CHECK-NEXT: 20000: 3c 02 00 00 lui $2, 0
[ELF][MIPS] Fix calculation of GOT "page address" entries number If output section which referenced by R_MIPS_GOT_PAGE or R_MIPS_GOT16 relocations is small (less that 0x10000 bytes) and occupies two adjacent 0xffff-bytes pages, current formula gives incorrect number of required "page" GOT entries. The problem is that in time of calculation we do not know the section address and so we cannot calculate number of 0xffff-bytes pages exactly. This patch fix the formula. Now it gives a correct number of pages in the worst case when "small" section intersects 0xffff-bytes page boundary. From the other side, sometimes it adds one more redundant GOT entry for each output section. But usually number of output sections referenced by GOT relocations is small. llvm-svn: 288127
2016-11-29 18:23:46 +08:00
# CHECK-NEXT: 20004: 8c 42 80 24 lw $2, -32732($2)
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
# CHECK-NEXT: 20008: 3c 02 00 00 lui $2, 0
[ELF][MIPS] Fix calculation of GOT "page address" entries number If output section which referenced by R_MIPS_GOT_PAGE or R_MIPS_GOT16 relocations is small (less that 0x10000 bytes) and occupies two adjacent 0xffff-bytes pages, current formula gives incorrect number of required "page" GOT entries. The problem is that in time of calculation we do not know the section address and so we cannot calculate number of 0xffff-bytes pages exactly. This patch fix the formula. Now it gives a correct number of pages in the worst case when "small" section intersects 0xffff-bytes page boundary. From the other side, sometimes it adds one more redundant GOT entry for each output section. But usually number of output sections referenced by GOT relocations is small. llvm-svn: 288127
2016-11-29 18:23:46 +08:00
# CHECK-NEXT: 2000c: 8c 42 80 28 lw $2, -32728($2)
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
#
# CHECK: bar:
[ELF][MIPS] Fix calculation of GOT "page address" entries number If output section which referenced by R_MIPS_GOT_PAGE or R_MIPS_GOT16 relocations is small (less that 0x10000 bytes) and occupies two adjacent 0xffff-bytes pages, current formula gives incorrect number of required "page" GOT entries. The problem is that in time of calculation we do not know the section address and so we cannot calculate number of 0xffff-bytes pages exactly. This patch fix the formula. Now it gives a correct number of pages in the worst case when "small" section intersects 0xffff-bytes page boundary. From the other side, sometimes it adds one more redundant GOT entry for each output section. But usually number of output sections referenced by GOT relocations is small. llvm-svn: 288127
2016-11-29 18:23:46 +08:00
# CHECK-NEXT: 20010: 8c 42 80 20 lw $2, -32736($2)
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
# CHECK-NEXT: 20014: 8c 42 80 18 lw $2, -32744($2)
# CHECK-NEXT: 20018: 20 42 00 00 addi $2, $2, 0
# CHECK: Contents of section .got:
[ELF][MIPS] Exclude mips .got from PT_GNU_RELRO segment On MIPS .got section cannot be included into the PT_GNU_RELRO segment. Sometimes it might work, but in general it is unsupported. One of the problem is that all sections marked by SHF_MIPS_GPREL should be grouped together because data in these sections is addressable with a gp relative address, but such sections might be writable. This patch exclude mips .got from PT_GNU_RELRO segment and group SHF_MIPS_GPREL sections. llvm-svn: 292161
2017-01-17 05:17:23 +08:00
# CHECK-NEXT: 30010 00000000 80000000 00030000 00040000
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
# ^ %hi(loc)
[ELF][MIPS] Fix calculation of GOT "page address" entries number If output section which referenced by R_MIPS_GOT_PAGE or R_MIPS_GOT16 relocations is small (less that 0x10000 bytes) and occupies two adjacent 0xffff-bytes pages, current formula gives incorrect number of required "page" GOT entries. The problem is that in time of calculation we do not know the section address and so we cannot calculate number of 0xffff-bytes pages exactly. This patch fix the formula. Now it gives a correct number of pages in the worst case when "small" section intersects 0xffff-bytes page boundary. From the other side, sometimes it adds one more redundant GOT entry for each output section. But usually number of output sections referenced by GOT relocations is small. llvm-svn: 288127
2016-11-29 18:23:46 +08:00
# ^ redundant entry
[ELF][MIPS] Exclude mips .got from PT_GNU_RELRO segment On MIPS .got section cannot be included into the PT_GNU_RELRO segment. Sometimes it might work, but in general it is unsupported. One of the problem is that all sections marked by SHF_MIPS_GPREL should be grouped together because data in these sections is addressable with a gp relative address, but such sections might be writable. This patch exclude mips .got from PT_GNU_RELRO segment and group SHF_MIPS_GPREL sections. llvm-svn: 292161
2017-01-17 05:17:23 +08:00
# CHECK-NEXT: 30020 00020010 00020000 00030000
[ELF][MIPS] Fix calculation of GOT "page address" entries number If output section which referenced by R_MIPS_GOT_PAGE or R_MIPS_GOT16 relocations is small (less that 0x10000 bytes) and occupies two adjacent 0xffff-bytes pages, current formula gives incorrect number of required "page" GOT entries. The problem is that in time of calculation we do not know the section address and so we cannot calculate number of 0xffff-bytes pages exactly. This patch fix the formula. Now it gives a correct number of pages in the worst case when "small" section intersects 0xffff-bytes page boundary. From the other side, sometimes it adds one more redundant GOT entry for each output section. But usually number of output sections referenced by GOT relocations is small. llvm-svn: 288127
2016-11-29 18:23:46 +08:00
# ^ %got(bar)
# ^ %got_hi/lo(start)
# ^ %got_hi/lo(loc)
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
ELF: Place relro sections after non-relro sections in r/w segment. This is in preparation for my next change, which will introduce a relro nobits section. That requires that relro sections appear at the end of the progbits part of the r/w segment so that the relro nobits section can appear contiguously. Because of the amount of churn required in the test suite, I'm making this change separately. llvm-svn: 291523
2017-01-10 09:21:30 +08:00
# CHECK: 00030000 .data 00000000 loc
[ELF][MIPS] Put local GOT entries accessed via a 16-bit index first Some MIPS relocations used to access GOT entries are able to manipulate 16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle 32-bit indexes. 16-bit relocations are generated by default. The 32-bit relocations are generated by -mxgot flag passed to compiler. Usually these relocation are not mixed in the same code but files like crt*.o contain 16-bit relocations so even if all "user's" code compiled with -mxgot flag a few 16-bit relocations might come to the linking phase. Now LLD does not differentiate local GOT entries accessed via a 16-bit and 32-bit indexes. That might lead to relocation's overflow if 16-bit entries are allocated to far from the beginning of the GOT. The patch introduces new "part" of MIPS GOT dedicated to the local GOT entries accessed by 32-bit relocations. That allows to put local GOT entries accessed via a 16-bit index first and escape relocation's overflow. Differential revision: https://reviews.llvm.org/D25833 llvm-svn: 284809
2016-10-21 15:22:30 +08:00
# CHECK: 00020000 .text 00000000 __start
# CHECK: 00020010 .text 00000000 bar
.text
.global __start, bar
__start:
lui $2, %got_hi(__start)
lw $2, %got_lo(__start)($2)
lui $2, %got_hi(loc)
lw $2, %got_lo(loc)($2)
bar:
lw $2, %got(bar)($2)
lw $2, %got(loc)($2)
addi $2, $2, %lo(loc)
.data
loc:
.word 0