6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-26 05:32:25 +00:00
Code Issues Projects Releases Wiki Activity
31c0b5bc44
llvm-6502/test/MC/PowerPC/ppc64-fixup-apply.s

108 lines
2.6 KiB
ArmAsm
Raw Normal View History

[PowerPC] Add test case for r181891 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181892 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 15:02:12 +00:00
# RUN: llvm-mc -triple powerpc64-unknown-unknown -filetype=obj %s | \
[PowerPC] Generate little-endian object files As a first step towards real little-endian code generation, this patch changes the PowerPC MC layer to actually generate little-endian object files. This involves passing the little-endian flag through the various layers, including down to createELFObjectWriter so we actually get basic little-endian ELF objects, emitting instructions in little-endian order, and handling fixups and relocations as appropriate for little-endian. The bulk of the patch is to update most test cases in test/MC/PowerPC to verify both big- and little-endian encodings. (The only test cases *not* updated are those that create actual big-endian ABI code, like the TLS tests.) Note that while the object files are now little-endian, the generated code itself is not yet updated, in particular, it still does not adhere to the ELFv2 ABI. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204634 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-24 18:16:09 +00:00
# RUN: llvm-readobj -s -sd | FileCheck -check-prefix=CHECK -check-prefix=CHECK-BE %s
# RUN: llvm-mc -triple powerpc64le-unknown-unknown -filetype=obj %s | \
# RUN: llvm-readobj -s -sd | FileCheck -check-prefix=CHECK -check-prefix=CHECK-LE %s
[PowerPC] Add test case for r181891 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181892 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 15:02:12 +00:00
# This checks that fixups that can be resolved within the same
# object file are applied correctly.
[PowerPC] Fix processing of ha16/lo16 fixups The current PowerPC MC back end distinguishes between fixup_ppc_ha16 and fixup_ppc_lo16, which are determined by the instruction the fixup applies to, and uses this distinction to decide whether a fixup ought to resolve to the high or the low part of a symbol address. This isn't quite correct, however. It is valid -if unusual- assembler to use, e.g. li 1, symbol@ha or lis 1, symbol@l Whether the high or the low part of the address is used depends solely on the @ suffix, not on the instruction. In addition, both li 1, symbol and lis 1, symbol are valid, assuming the symbol address fits into 16 bits; again, both will then refer to the actual symbol value (so li will load the value itself, while lis will load the value shifted by 16). To fix this, two places need to be adapted. If the fixup cannot be resolved at assembler time, a relocation needs to be emitted via PPCELFObjectWriter::getRelocType. This routine already looks at the VK_ type to determine the relocation. The only problem is that will reject any _LO modifier in a ha16 fixup and vice versa. This is simply incorrect; any of those modifiers ought to be accepted for either fixup type. If the fixup *can* be resolved at assembler time, adjustFixupValue currently selects the high bits of the symbol value if the fixup type is ha16. Again, this is incorrect; see the above example lis 1, symbol Now, in theory we'd have to respect a VK_ modifier here. However, in fact common code never even attempts to resolve symbol references using any nontrivial VK_ modifier at assembler time; it will always fall back to emitting a reloc and letting the linker handle it. If this ever changes, presumably there'd have to be a target callback to resolve VK_ modifiers. We'd then have to handle @ha etc. there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182091 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-17 12:36:29 +00:00
.text
addi 1, 1, target
addis 1, 1, target
.set target, 0x1234
[PowerPC] Optimize @ha/@l constructs This patch adds support for having the assembler optimize fixups to constructs like "symbol@ha" or "symbol@l" if "symbol" can be resolved at assembler time. This optimization is already present in the PPCMCExpr.cpp code for handling PPC_HA16/PPC_LO16 target expressions. However, those target expression were used only on Darwin targets. This patch changes target expression code so that they are usable also with the GNU assembler (using the @ha / @l syntax instead of the ha16() / lo16() syntax), and changes the MCInst lowering code to generate those target expressions where appropriate. It also changes the asm parser to generate HA16/LO16 target expressions when parsing assembler source that uses the @ha / @l modifiers. The effect is that now the above- mentioned optimization automatically becomes available for those situations too. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184436 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-20 16:23:52 +00:00
addi 1, 1, target2@l
addis 1, 1, target2@ha
.set target2, 0x12345678
addi 1, 1, target3-target4@l
addis 1, 1, target3-target4@ha
.set target3, 0x23455678
.set target4, 0x12341234
addi 1, 1, target5+0x8000@l
addis 1, 1, target5+0x8000@ha
.set target5, 0x10000001
[MC] Support @ variants with directional labels The assembler parser common code supports recognizing symbol variants using the @ modifer. On PowerPC, it should also be possible to use (some of) those modifiers with directional labels, like "1f@l". This patch adds support for accepting symbol variants on directional labels as well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184437 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-20 16:24:17 +00:00
1:
addi 1, 1, 2f-1b@l
addis 1, 1, 1b-2f@ha
2:
[PowerPC] Support @h modifier This adds necessary infrastructure to support the @h modifier. Note that all required relocation types were already present (and unused). This patch provides support for using @h in the assembler; it would also be possible to now use this feature in code generated by the compiler, but this is not done yet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184548 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-21 14:42:49 +00:00
addi 1, 1, target6@h
addis 1, 1, target6@h
.set target6, 0x4321fedc
[PowerPC] Support @higher et.al. modifiers This adds support for the @higher, @highera, @highest, and @highesta modifers, including some missing relocation types. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184550 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-21 14:43:42 +00:00
addi 1, 1, target7@higher
addis 1, 1, target7@highest
addi 1, 1, target7@highera
addis 1, 1, target7@highesta
.set target7, 0x1234ffffffff8000
[PowerPC] Add test case for r181891 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181892 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 15:02:12 +00:00
.data
.quad v1
[PowerPC] Support .llong and fix .word This adds support for the .llong PowerPC-specifc assembler directive. In doing so, I notices that .word is currently incorrect: it is supposed to define a 2-byte data element, not a 4-byte one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185911 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-09 07:59:25 +00:00
.long v2
[PowerPC] Add test case for r181891 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181892 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 15:02:12 +00:00
.short v3
.byte v4
.set v1, 0x123456789abcdef0
.set v2, 0x87654321
.set v3, 0xbeef
.set v4, 0x42
[PowerPC] Fix processing of ha16/lo16 fixups The current PowerPC MC back end distinguishes between fixup_ppc_ha16 and fixup_ppc_lo16, which are determined by the instruction the fixup applies to, and uses this distinction to decide whether a fixup ought to resolve to the high or the low part of a symbol address. This isn't quite correct, however. It is valid -if unusual- assembler to use, e.g. li 1, symbol@ha or lis 1, symbol@l Whether the high or the low part of the address is used depends solely on the @ suffix, not on the instruction. In addition, both li 1, symbol and lis 1, symbol are valid, assuming the symbol address fits into 16 bits; again, both will then refer to the actual symbol value (so li will load the value itself, while lis will load the value shifted by 16). To fix this, two places need to be adapted. If the fixup cannot be resolved at assembler time, a relocation needs to be emitted via PPCELFObjectWriter::getRelocType. This routine already looks at the VK_ type to determine the relocation. The only problem is that will reject any _LO modifier in a ha16 fixup and vice versa. This is simply incorrect; any of those modifiers ought to be accepted for either fixup type. If the fixup *can* be resolved at assembler time, adjustFixupValue currently selects the high bits of the symbol value if the fixup type is ha16. Again, this is incorrect; see the above example lis 1, symbol Now, in theory we'd have to respect a VK_ modifier here. However, in fact common code never even attempts to resolve symbol references using any nontrivial VK_ modifier at assembler time; it will always fall back to emitting a reloc and letting the linker handle it. If this ever changes, presumably there'd have to be a target callback to resolve VK_ modifiers. We'd then have to handle @ha etc. there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182091 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-17 12:36:29 +00:00
# CHECK: Section {
# CHECK: Name: .text
# CHECK-NEXT: Type: SHT_PROGBITS
# CHECK-NEXT: Flags [
# CHECK-NEXT: SHF_ALLOC
# CHECK-NEXT: SHF_EXECINSTR
# CHECK-NEXT: ]
# CHECK-NEXT: Address: 0x0
# CHECK-NEXT: Offset:
[PowerPC] Support @higher et.al. modifiers This adds support for the @higher, @highera, @highest, and @highesta modifers, including some missing relocation types. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184550 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-21 14:43:42 +00:00
# CHECK-NEXT: Size: 64
[PowerPC] Fix processing of ha16/lo16 fixups The current PowerPC MC back end distinguishes between fixup_ppc_ha16 and fixup_ppc_lo16, which are determined by the instruction the fixup applies to, and uses this distinction to decide whether a fixup ought to resolve to the high or the low part of a symbol address. This isn't quite correct, however. It is valid -if unusual- assembler to use, e.g. li 1, symbol@ha or lis 1, symbol@l Whether the high or the low part of the address is used depends solely on the @ suffix, not on the instruction. In addition, both li 1, symbol and lis 1, symbol are valid, assuming the symbol address fits into 16 bits; again, both will then refer to the actual symbol value (so li will load the value itself, while lis will load the value shifted by 16). To fix this, two places need to be adapted. If the fixup cannot be resolved at assembler time, a relocation needs to be emitted via PPCELFObjectWriter::getRelocType. This routine already looks at the VK_ type to determine the relocation. The only problem is that will reject any _LO modifier in a ha16 fixup and vice versa. This is simply incorrect; any of those modifiers ought to be accepted for either fixup type. If the fixup *can* be resolved at assembler time, adjustFixupValue currently selects the high bits of the symbol value if the fixup type is ha16. Again, this is incorrect; see the above example lis 1, symbol Now, in theory we'd have to respect a VK_ modifier here. However, in fact common code never even attempts to resolve symbol references using any nontrivial VK_ modifier at assembler time; it will always fall back to emitting a reloc and letting the linker handle it. If this ever changes, presumably there'd have to be a target callback to resolve VK_ modifiers. We'd then have to handle @ha etc. there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182091 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-17 12:36:29 +00:00
# CHECK-NEXT: Link: 0
# CHECK-NEXT: Info: 0
# CHECK-NEXT: AddressAlignment: 4
# CHECK-NEXT: EntrySize: 0
# CHECK-NEXT: SectionData (
[PowerPC] Generate little-endian object files As a first step towards real little-endian code generation, this patch changes the PowerPC MC layer to actually generate little-endian object files. This involves passing the little-endian flag through the various layers, including down to createELFObjectWriter so we actually get basic little-endian ELF objects, emitting instructions in little-endian order, and handling fixups and relocations as appropriate for little-endian. The bulk of the patch is to update most test cases in test/MC/PowerPC to verify both big- and little-endian encodings. (The only test cases *not* updated are those that create actual big-endian ABI code, like the TLS tests.) Note that while the object files are now little-endian, the generated code itself is not yet updated, in particular, it still does not adhere to the ELFv2 ABI. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204634 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-24 18:16:09 +00:00
# CHECK-BE-NEXT: 0000: 38211234 3C211234 38215678 3C211234
# CHECK-LE-NEXT: 0000: 34122138 3412213C 78562138 3412213C
# CHECK-BE-NEXT: 0010: 38214444 3C211111 38218001 3C211001
# CHECK-LE-NEXT: 0010: 44442138 1111213C 01802138 0110213C
# CHECK-BE-NEXT: 0020: 38210008 3C210000 38214321 3C214321
# CHECK-LE-NEXT: 0020: 08002138 0000213C 21432138 2143213C
# CHECK-BE-NEXT: 0030: 3821FFFF 3C211234 38210000 3C211235
# CHECK-LE-NEXT: 0030: FFFF2138 3412213C 00002138 3512213C
[PowerPC] Fix processing of ha16/lo16 fixups The current PowerPC MC back end distinguishes between fixup_ppc_ha16 and fixup_ppc_lo16, which are determined by the instruction the fixup applies to, and uses this distinction to decide whether a fixup ought to resolve to the high or the low part of a symbol address. This isn't quite correct, however. It is valid -if unusual- assembler to use, e.g. li 1, symbol@ha or lis 1, symbol@l Whether the high or the low part of the address is used depends solely on the @ suffix, not on the instruction. In addition, both li 1, symbol and lis 1, symbol are valid, assuming the symbol address fits into 16 bits; again, both will then refer to the actual symbol value (so li will load the value itself, while lis will load the value shifted by 16). To fix this, two places need to be adapted. If the fixup cannot be resolved at assembler time, a relocation needs to be emitted via PPCELFObjectWriter::getRelocType. This routine already looks at the VK_ type to determine the relocation. The only problem is that will reject any _LO modifier in a ha16 fixup and vice versa. This is simply incorrect; any of those modifiers ought to be accepted for either fixup type. If the fixup *can* be resolved at assembler time, adjustFixupValue currently selects the high bits of the symbol value if the fixup type is ha16. Again, this is incorrect; see the above example lis 1, symbol Now, in theory we'd have to respect a VK_ modifier here. However, in fact common code never even attempts to resolve symbol references using any nontrivial VK_ modifier at assembler time; it will always fall back to emitting a reloc and letting the linker handle it. If this ever changes, presumably there'd have to be a target callback to resolve VK_ modifiers. We'd then have to handle @ha etc. there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182091 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-17 12:36:29 +00:00
# CHECK-NEXT: )
# CHECK-NEXT: }
[PowerPC] Add test case for r181891 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181892 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 15:02:12 +00:00
# CHECK: Section {
# CHECK: Name: .data
# CHECK-NEXT: Type: SHT_PROGBITS
# CHECK-NEXT: Flags [
# CHECK-NEXT: SHF_ALLOC
# CHECK-NEXT: SHF_WRITE
# CHECK-NEXT: ]
# CHECK-NEXT: Address: 0x0
# CHECK-NEXT: Offset:
# CHECK-NEXT: Size: 15
# CHECK-NEXT: Link: 0
# CHECK-NEXT: Info: 0
# CHECK-NEXT: AddressAlignment: 4
# CHECK-NEXT: EntrySize: 0
# CHECK-NEXT: SectionData (
[PowerPC] Generate little-endian object files As a first step towards real little-endian code generation, this patch changes the PowerPC MC layer to actually generate little-endian object files. This involves passing the little-endian flag through the various layers, including down to createELFObjectWriter so we actually get basic little-endian ELF objects, emitting instructions in little-endian order, and handling fixups and relocations as appropriate for little-endian. The bulk of the patch is to update most test cases in test/MC/PowerPC to verify both big- and little-endian encodings. (The only test cases *not* updated are those that create actual big-endian ABI code, like the TLS tests.) Note that while the object files are now little-endian, the generated code itself is not yet updated, in particular, it still does not adhere to the ELFv2 ABI. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204634 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-24 18:16:09 +00:00
# CHECK-BE-NEXT: 0000: 12345678 9ABCDEF0 87654321 BEEF42
# CHECK-LE-NEXT: 0000: F0DEBC9A 78563412 21436587 EFBE42
[PowerPC] Add test case for r181891 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181892 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 15:02:12 +00:00
# CHECK-NEXT: )
# CHECK-NEXT: }
Reference in New Issue Copy Permalink