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-8-large-addend.s

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

13 lines
277 B
ArmAsm
Raw Normal View History

[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
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=i386-pc-linux %s -o %t
# RUN: ld.lld -Ttext 0x7c %t -o %t2
# RUN: llvm-objdump -s %t2 | FileCheck %s
# CHECK: Contents of section .text:
# CHECK-NEXT: 007c b4ff
.code16
.global _start
_start:
movb $_start+0x83,%ah