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
425 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
[llvm-objdump] Further rearrange llvm-objdump sections for compatability Summary: rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more. I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump: * Archive headers * File headers * Section headers * Symbol table * Dwarf debugging * Relocations (if `--disassemble` is not used) * Section contents * Disassembly Reviewers: jhenderson, justice_adams, grimar, ychen, espindola Reviewed By: jhenderson Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68066 llvm-svn: 373671
2019-10-04 06:01:08 +08:00
# CHECK: SYMBOL TABLE:
[llvm-objdump] --syms: make flags closer to GNU objdump This fixes several issues. The behavior changes are: A SHN_COMMON symbol does not have the 'g' flag. An undefined symbol does not have 'g' or 'l' flag. A STB_GLOBAL SymbolRef::ST_Unknown symbol has the 'g' flag. A STB_LOCAL SymbolRef::ST_Unknown symbol has the 'l' flag. Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75659
2020-03-05 09:19:18 +08:00
# CHECK: 004010b7 l .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
# 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
.byte und-.-1
.short und-.-2
.section .und, "ax"
und: