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-pc8-pc16-addend.s

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

18 lines
423 B
ArmAsm
Raw Normal View History

[ELF] - Use SignExtend when reading R_386_PC8, R_386_PC16 addends. Previously we did not do that. For example, for R_386_PC8, 0xFF addend was not treated as 0xFFFFFFFF(-1), but was 0x000000FF. Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation overflow as a result. Differential revision: https://reviews.llvm.org/D29490 llvm-svn: 294289
2017-02-07 17:58:27 +08:00
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=i386-pc-linux-gnu %s -o %t1.o
# RUN: ld.lld %t1.o -o %t.out
# RUN: llvm-objdump -s -t %t.out | FileCheck %s
# CHECK: Contents of section .text:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_386 Ported the D64906 technique to EM_386. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * FreeBSD 13.0-CURRENT rtld-elf * glibc https://sourceware.org/bugzilla/show_bug.cgi?id=24606 New test i386-tls-vaddr-align.s checks our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65865 llvm-svn: 369347
2019-08-20 16:43:47 +08:00
# CHECK-NEXT: 4010b4 020000
## 0x4010b7 - 0x4010b4 + addend(-1) = 0x02
## 0x4010b7 - 0x4010b5 + addend(-2) = 0x0000
[ELF] - Use SignExtend when reading R_386_PC8, R_386_PC16 addends. Previously we did not do that. For example, for R_386_PC8, 0xFF addend was not treated as 0xFFFFFFFF(-1), but was 0x000000FF. Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation overflow as a result. Differential revision: https://reviews.llvm.org/D29490 llvm-svn: 294289
2017-02-07 17:58:27 +08:00
# CHECK: SYMBOL TABLE:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_386 Ported the D64906 technique to EM_386. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * FreeBSD 13.0-CURRENT rtld-elf * glibc https://sourceware.org/bugzilla/show_bug.cgi?id=24606 New test i386-tls-vaddr-align.s checks our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65865 llvm-svn: 369347
2019-08-20 16:43:47 +08:00
# CHECK: 004010b7 .und
[ELF] - Use SignExtend when reading R_386_PC8, R_386_PC16 addends. Previously we did not do that. For example, for R_386_PC8, 0xFF addend was not treated as 0xFFFFFFFF(-1), but was 0x000000FF. Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation overflow as a result. Differential revision: https://reviews.llvm.org/D29490 llvm-svn: 294289
2017-02-07 17:58:27 +08:00
.byte und-.-1
.short und-.-2
.section .und, "ax"
und: