2017-02-14 05:29:56 +08:00
|
|
|
// REQUIRES: x86
|
|
|
|
|
|
|
|
|
|
// RUN: llvm-mc -filetype=obj -triple=i386-pc-linux %S/Inputs/i386-reloc-8.s -o %t1
|
|
|
|
|
// RUN: llvm-mc -filetype=obj -triple=i386-pc-linux %S/Inputs/i386-reloc-8-error.s -o %t2
|
|
|
|
|
// RUN: llvm-mc -filetype=obj -triple=i386-pc-linux %s -o %t
|
|
|
|
|
// RUN: ld.lld -shared %t %t1 -o %t3
|
2018-03-29 22:57:29 +08:00
|
|
|
// RUN: llvm-objdump -s %t3 | FileCheck %s
|
2017-02-14 05:29:56 +08:00
|
|
|
|
|
|
|
|
// CHECK: Contents of section .text:
|
2018-03-29 22:57:29 +08:00
|
|
|
// CHECK-NEXT: 1000 ff
|
2017-02-14 05:29:56 +08:00
|
|
|
|
2018-07-03 01:48:23 +08:00
|
|
|
// RUN: not ld.lld -shared %t %t2 -o /dev/null 2>&1 | FileCheck --check-prefix=ERROR %s
|
[ELF] - Relax checks for R_386_8/R_386_16 relocations.
This fixes PR36927.
The issue is next. Imagine we have -Ttext 0x7c and code below.
.code16
.global _start
_start:
movb $_start+0x83,%ah
So we have R_386_8 relocation and _start at 0x7C.
Addend is 0x83 == 131. We will sign extend it to 0xffffffffffffff83.
Now, 0xffffffffffffff83 + 0x7c gives us 0xFFFFFFFFFFFFFFFF.
Techically 0x83 + 0x7c == 0xFF, we do not exceed 1 byte value, but
currently LLD errors out, because we use checkUInt<8>.
Let's try to use checkInt<8> now and the following code to see if it can help (no):
main.s:
.byte foo
input.s:
.globl foo
.hidden foo
foo = 0xff
Here, foo is 0xFF. And addend is 0x0. Final value is 0x00000000000000FF.
Again, it fits one byte well, but with checkInt<8>,
we would error out it, so we can't use it.
What we want to do is to check that the result fits 1 byte well.
Patch changes the check to checkIntUInt to fix the issue.
Differential revision: https://reviews.llvm.org/D45051
llvm-svn: 329061
2018-04-03 20:19:04 +08:00
|
|
|
// ERROR: relocation R_386_8 out of range: 256 is not in [-128, 127]
|
2017-02-14 05:29:56 +08:00
|
|
|
|
|
|
|
|
.byte foo
|
