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/mips-hilo-hi-only.s

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

27 lines
819 B
ArmAsm
Raw Normal View History

[ELF] Move `# REQUIRES:` line to the top llvm-svn: 335625
2018-06-27 00:58:19 +08:00
# REQUIRES: mips
[ELF] MIPS paired R_MIPS_HI16/LO16 relocations support Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined addends. Such addend is calculated using addends of both paired relocations. Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16` relocation. ABI requires to compute such combined addend in case of REL relocation record format only. For details see p. 4-17 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf This patch implements lookup of the next paired relocation suing new `InputSectionBase::findPairedRelocLocation` method. The primary disadvantage of this approach is that we put MIPS specific logic into the common code. The next disadvantage is that we lookup `R_MIPS_LO16` for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16` might be paired with the single `R_MIPS_LO16`. From the other side this way allows us to keep `MipsTargetInfo` class stateless and implement later relocation handling in parallel. This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against `_gp_disp` symbol. In that case the relocations use a special formula for the calculation. That will be implemented later. Differential Revision: http://reviews.llvm.org/D15112 llvm-svn: 254461
2015-12-02 05:24:45 +08:00
# Check warning on orphaned R_MIPS_HI16 relocations.
# RUN: llvm-mc -filetype=obj -triple=mips-unknown-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t.exe 2>&1 | FileCheck -check-prefix=WARN %s
[mips] Make another set of test cases more tolerant to exact symbol addresses. NFC llvm-svn: 371313
2019-09-07 23:44:40 +08:00
# RUN: llvm-objdump -d -t --print-imm-hex --no-show-raw-insn %t.exe | FileCheck %s
[ELF] MIPS paired R_MIPS_HI16/LO16 relocations support Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined addends. Such addend is calculated using addends of both paired relocations. Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16` relocation. ABI requires to compute such combined addend in case of REL relocation record format only. For details see p. 4-17 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf This patch implements lookup of the next paired relocation suing new `InputSectionBase::findPairedRelocLocation` method. The primary disadvantage of this approach is that we put MIPS specific logic into the common code. The next disadvantage is that we lookup `R_MIPS_LO16` for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16` might be paired with the single `R_MIPS_LO16`. From the other side this way allows us to keep `MipsTargetInfo` class stateless and implement later relocation handling in parallel. This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against `_gp_disp` symbol. In that case the relocations use a special formula for the calculation. That will be implemented later. Differential Revision: http://reviews.llvm.org/D15112 llvm-svn: 254461
2015-12-02 05:24:45 +08:00
.text
.globl __start
__start:
lui $t0,%hi(__start+0x10000)
[ELF][MIPS] Match paired relocation using relocation type and symbol index If we have R_MIPS_HI16 relocation, the paired relocation is the next R_MIPS_LO16 relocation with the same symbol as a target. llvm-svn: 255452
2015-12-13 14:49:08 +08:00
addi $t0,$t0,%lo(_label)
_label:
nop
[ELF] MIPS paired R_MIPS_HI16/LO16 relocations support Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined addends. Such addend is calculated using addends of both paired relocations. Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16` relocation. ABI requires to compute such combined addend in case of REL relocation record format only. For details see p. 4-17 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf This patch implements lookup of the next paired relocation suing new `InputSectionBase::findPairedRelocLocation` method. The primary disadvantage of this approach is that we put MIPS specific logic into the common code. The next disadvantage is that we lookup `R_MIPS_LO16` for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16` might be paired with the single `R_MIPS_LO16`. From the other side this way allows us to keep `MipsTargetInfo` class stateless and implement later relocation handling in parallel. This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against `_gp_disp` symbol. In that case the relocations use a special formula for the calculation. That will be implemented later. Differential Revision: http://reviews.llvm.org/D15112 llvm-svn: 254461
2015-12-02 05:24:45 +08:00
Error/warning/log messages should start with lowercase letters. llvm-svn: 263549
2016-03-15 22:00:22 +08:00
# WARN: can't find matching R_MIPS_LO16 relocation for R_MIPS_HI16
[ELF] MIPS paired R_MIPS_HI16/LO16 relocations support Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined addends. Such addend is calculated using addends of both paired relocations. Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16` relocation. ABI requires to compute such combined addend in case of REL relocation record format only. For details see p. 4-17 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf This patch implements lookup of the next paired relocation suing new `InputSectionBase::findPairedRelocLocation` method. The primary disadvantage of this approach is that we put MIPS specific logic into the common code. The next disadvantage is that we lookup `R_MIPS_LO16` for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16` might be paired with the single `R_MIPS_LO16`. From the other side this way allows us to keep `MipsTargetInfo` class stateless and implement later relocation handling in parallel. This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against `_gp_disp` symbol. In that case the relocations use a special formula for the calculation. That will be implemented later. Differential Revision: http://reviews.llvm.org/D15112 llvm-svn: 254461
2015-12-02 05:24:45 +08:00
[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: 00020{{0*}}[[VAL:[0-9a-f]+]] l .text 00000000 _label
# CHECK: 00020{{.*}} g .text 00000000 __start
[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
[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: <__start>:
[mips] Make another set of test cases more tolerant to exact symbol addresses. NFC llvm-svn: 371313
2019-09-07 23:44:40 +08:00
# CHECK-NEXT: lui $8, 0x3
# ^-- %hi(__start) w/o addend
[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-NEXT: addi $8, $8, 0x[[VAL]]
[mips] Make another set of test cases more tolerant to exact symbol addresses. NFC llvm-svn: 371313
2019-09-07 23:44:40 +08:00
# ^-- %lo(_label)