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/i386-reloc-range.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

25 lines
890 B
ArmAsm
Raw Normal View History

[LLD] Mark a number of x86 only tests to require x86 Noticed while testing for an out of tree target. There are probably more tests that should be so marked. I'm not sure who owns these tests so I've added a few names I recognise from the recent history. With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all! Differential Revision: https://reviews.llvm.org/D34685 llvm-svn: 308335
2017-07-19 02:40:50 +08:00
// REQUIRES: x86
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
// RUN: llvm-mc %s -o %t.o -triple i386-pc-linux-code16 -filetype=obj
Relax the overflow checking of R_386_PC16. Currently the freebsd early boot code fails to link. The issue reduces to 16 bit code at position 0x7000 wanting to jump to position 0x9000. That is represented in the .o file as a relocation with no symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip after the current instruction for jumps). If the addend is interpreted as signed (it should), it is -28674. In a 32 bit architecture, that is the address 0xffff8ffe. To get there from 0x7000 we have to add 4294909950 (too big) or subtract 57346 (too small). We then produce an error. What lld is missing is the fact that at runtime this will actually be a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the correct result in 16 bits (-28674). Since we have a 16 bit addend and a 16 bit PC, the relocation can move the PC to any 16 bit address and that is the only thing we really need to check: if the address we are pointing to fits in 16 bits. This is unfortunately hard to do since we have to delay subtracting the PC and if we want to do that outside of Target.cpp, we have to move the overflow check out too. An incomplete patch that tries to do that is at https://reviews.llvm.org/D34070 This patch instead just relaxes the check. Since the value we have is the destination minus the PC and the PC is 16 bits, it should fit in 17 bits if the destination fits in 16 too. bfd had a similar issue for some time and got a similar fix: https://sourceware.org/ml/binutils/2005-08/msg00001.html llvm-svn: 305135
2017-06-10 09:56:58 +08:00
// RUN: echo ".global foo; foo = 0x10202" > %t1.s
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
// RUN: llvm-mc %t1.s -o %t1.o -triple i386-pc-linux -filetype=obj
Relax the overflow checking of R_386_PC16. Currently the freebsd early boot code fails to link. The issue reduces to 16 bit code at position 0x7000 wanting to jump to position 0x9000. That is represented in the .o file as a relocation with no symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip after the current instruction for jumps). If the addend is interpreted as signed (it should), it is -28674. In a 32 bit architecture, that is the address 0xffff8ffe. To get there from 0x7000 we have to add 4294909950 (too big) or subtract 57346 (too small). We then produce an error. What lld is missing is the fact that at runtime this will actually be a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the correct result in 16 bits (-28674). Since we have a 16 bit addend and a 16 bit PC, the relocation can move the PC to any 16 bit address and that is the only thing we really need to check: if the address we are pointing to fits in 16 bits. This is unfortunately hard to do since we have to delay subtracting the PC and if we want to do that outside of Target.cpp, we have to move the overflow check out too. An incomplete patch that tries to do that is at https://reviews.llvm.org/D34070 This patch instead just relaxes the check. Since the value we have is the destination minus the PC and the PC is 16 bits, it should fit in 17 bits if the destination fits in 16 too. bfd had a similar issue for some time and got a similar fix: https://sourceware.org/ml/binutils/2005-08/msg00001.html llvm-svn: 305135
2017-06-10 09:56:58 +08:00
// RUN: echo ".global foo; foo = 0x10203" > %t2.s
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
// RUN: llvm-mc %t2.s -o %t2.o -triple i386-pc-linux -filetype=obj
// RUN: ld.lld -Ttext 0x200 %t.o %t1.o -o %t1
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
// RUN: llvm-objdump -d --no-show-raw-insn --triple=i386-pc-linux-code16 %t1 | FileCheck %s
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
// 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:
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK-NEXT: <_start>:
[X86InstPrinter] Change printPCRelImm to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 400000: e8 0b 00 00 00 callq 11 400005: e8 0b 00 00 00 callq 11 // llvm-objdump -d output (after) 400000: e8 0b 00 00 00 callq 0x400010 400005: e8 0b 00 00 00 callq 0x400015 // GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled 400000: e8 0b 00 00 00 callq 400010 400005: e8 0b 00 00 00 callq 400015 ``` In llvm-objdump, we pass the address of the next MCInst. Ideally we should just thread the address of the current address, unfortunately we cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter requires MCInstrInfo and MCContext) to get the length of the MCInst. MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0. They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76580
2020-03-23 06:03:10 +08:00
// CHECK-NEXT: 200: jmp 0x202
Relax the overflow checking of R_386_PC16. Currently the freebsd early boot code fails to link. The issue reduces to 16 bit code at position 0x7000 wanting to jump to position 0x9000. That is represented in the .o file as a relocation with no symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip after the current instruction for jumps). If the addend is interpreted as signed (it should), it is -28674. In a 32 bit architecture, that is the address 0xffff8ffe. To get there from 0x7000 we have to add 4294909950 (too big) or subtract 57346 (too small). We then produce an error. What lld is missing is the fact that at runtime this will actually be a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the correct result in 16 bits (-28674). Since we have a 16 bit addend and a 16 bit PC, the relocation can move the PC to any 16 bit address and that is the only thing we really need to check: if the address we are pointing to fits in 16 bits. This is unfortunately hard to do since we have to delay subtracting the PC and if we want to do that outside of Target.cpp, we have to move the overflow check out too. An incomplete patch that tries to do that is at https://reviews.llvm.org/D34070 This patch instead just relaxes the check. Since the value we have is the destination minus the PC and the PC is 16 bits, it should fit in 17 bits if the destination fits in 16 too. bfd had a similar issue for some time and got a similar fix: https://sourceware.org/ml/binutils/2005-08/msg00001.html llvm-svn: 305135
2017-06-10 09:56:58 +08:00
// 0x10202 - 0x203 == 0xffff
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
[ELF] Replace unused output filenames with /dev/null in tests Post commit review at rLLD335992 llvm-svn: 336129
2018-07-03 01:48:23 +08:00
// RUN: not ld.lld -Ttext 0x200 %t.o %t2.o -o /dev/null 2>&1 | FileCheck --check-prefix=ERR %s
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
[ELF] Mention symbol name in reportRangeError() For an out-of-range relocation referencing a non-local symbol, report the symbol name and the object file that defines the symbol. As an example: ``` t.o:(function func: .text.func+0x3): relocation R_X86_64_32S out of range: -281474974609120 is not in [-2147483648, 2147483647] ``` => ``` t.o:(function func: .text.func+0x3): relocation R_X86_64_32S out of range: -281474974609120 is not in [-2147483648, 2147483647]; references func >>> defined in t1.o ``` Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D73518
2020-01-28 09:35:06 +08:00
// ERR: {{.*}}:(.text+0x1): relocation R_386_PC16 out of range: 65536 is not in [-65536, 65535]; references foo
Add a test for R_386_PC16 range checking. llvm-svn: 305040
2017-06-09 08:48:55 +08:00
.global _start
_start:
jmp foo