RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 16:33:37 +01:00
Code Issues Projects Releases Wiki Activity
3e8393e6f7
llvm-mirror/test/MC/ARM/elf-movt.s

40 lines
1.4 KiB
ArmAsm
Raw Normal View History

Workaround for bug 8721. .s Test added. llvm-svn: 123292
2011-01-12 00:53:41 +01:00
@ RUN: llvm-mc %s -triple=armv7-linux-gnueabi | FileCheck -check-prefix=ASM %s
1. Support ELF pcrel relocations for movw/movt: R_ARM_MOVT_PREL and R_ARM_MOVW_PREL_NC. 2. Fix minor bug in ARMAsmPrinter - treat bitfield flag as a bitfield, not an enum. 3. Add support for 3 new elf section types (no-ops) llvm-svn: 123294
2011-01-12 01:19:25 +01:00
@ RUN: llvm-mc %s -triple=armv7-linux-gnueabi -filetype=obj -o - | \
@ RUN: elf-dump --dump-section-data | FileCheck -check-prefix=OBJ %s
Workaround for bug 8721. .s Test added. llvm-svn: 123292
2011-01-12 00:53:41 +01:00
.syntax unified
.text
.globl barf
.align 2
.type barf,%function
barf: @ @barf
@ BB#0: @ %entry
movw r0, :lower16:GOT-(.LPC0_2+8)
This fixes one divergence between LLVM and binutils for ARM in the text section. Assume the following bit of annotated assembly: .section .data.rel.ro,"aw",%progbits .align 2 .LAlpha: .long startval(GOTOFF) .text .align 2 .type main,%function .align 4 main: ;;; assume "main" starts at offset 0x20 0x0 push {r11, lr} 0x4 movw r0, :lower16:(.LAlpha-(.LBeta+8)) ;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8) ;;; ==> (??? - ((16-4) + 8) = -20 0x8 movt r0, :upper16:(.LAlpha-(.LBeta+8)) ;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8) ;;; ==> (??? - ((16-8) + 8) = -16 0xc ... blah .LBeta: 0x10 add r0, pc, r0 0x14 ... blah .LGamma: 0x18 add r1, pc, r1 Above snippet results in the following relocs in the .o file for the first pair of movw/movt instructions 00000024 R_ARM_MOVW_PREL_NC .LAlpha 00000028 R_ARM_MOVT_PREL .LAlpha And the encoded instructions in the .o file for main: must be 00000020 <main>: 20: e92d4800 push {fp, lr} 24: e30f0fec movw r0, #65516 ; 0xffec i.e. -20 28: e34f0ff0 movt r0, #65520 ; 0xfff0 i.e. -16 However, llc (prior to this commit) generates the following sequence 00000020 <main>: 20: e92d4800 push {fp, lr} 24: e30f0fec movw r0, #65516 ; 0xffec - i.e. -20 28: e34f0fff movt r0, #65535 ; 0xffff - i.e. -1 What has to happen in the ArmAsmBackend is that if the relocation is PC relative, the 16 bits encoded as part of movw and movt must be both addends, not addresses. It makes sense to encode addresses by right shifting the value by 16, but the result is incorrect for PIC. i.e., the right shift by 16 for movt is ONLY valid for the NON-PCRel case. This change agrees with what GNU as does, and makes the PIC code run. MC/ARM/elf-movt.s covers this case. llvm-svn: 131674
2011-05-19 22:55:25 +02:00
movt r0, :upper16:GOT-(.LPC0_2+8)
Workaround for bug 8721. .s Test added. llvm-svn: 123292
2011-01-12 00:53:41 +01:00
.LPC0_2:
Model :upper16: and :lower16: as ARM specific MCTargetExpr. This is a step in the right direction. It eliminated some hacks and will unblock codegen work. But it's far from being done. It doesn't reject illegal expressions, e.g. (FOO - :lower16:BAR). It also doesn't work in Thumb2 mode at all. llvm-svn: 123369
2011-01-13 08:58:56 +01:00
@ ASM: movw r0, :lower16:(GOT-(.LPC0_2+8))
This fixes one divergence between LLVM and binutils for ARM in the text section. Assume the following bit of annotated assembly: .section .data.rel.ro,"aw",%progbits .align 2 .LAlpha: .long startval(GOTOFF) .text .align 2 .type main,%function .align 4 main: ;;; assume "main" starts at offset 0x20 0x0 push {r11, lr} 0x4 movw r0, :lower16:(.LAlpha-(.LBeta+8)) ;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8) ;;; ==> (??? - ((16-4) + 8) = -20 0x8 movt r0, :upper16:(.LAlpha-(.LBeta+8)) ;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8) ;;; ==> (??? - ((16-8) + 8) = -16 0xc ... blah .LBeta: 0x10 add r0, pc, r0 0x14 ... blah .LGamma: 0x18 add r1, pc, r1 Above snippet results in the following relocs in the .o file for the first pair of movw/movt instructions 00000024 R_ARM_MOVW_PREL_NC .LAlpha 00000028 R_ARM_MOVT_PREL .LAlpha And the encoded instructions in the .o file for main: must be 00000020 <main>: 20: e92d4800 push {fp, lr} 24: e30f0fec movw r0, #65516 ; 0xffec i.e. -20 28: e34f0ff0 movt r0, #65520 ; 0xfff0 i.e. -16 However, llc (prior to this commit) generates the following sequence 00000020 <main>: 20: e92d4800 push {fp, lr} 24: e30f0fec movw r0, #65516 ; 0xffec - i.e. -20 28: e34f0fff movt r0, #65535 ; 0xffff - i.e. -1 What has to happen in the ArmAsmBackend is that if the relocation is PC relative, the 16 bits encoded as part of movw and movt must be both addends, not addresses. It makes sense to encode addresses by right shifting the value by 16, but the result is incorrect for PIC. i.e., the right shift by 16 for movt is ONLY valid for the NON-PCRel case. This change agrees with what GNU as does, and makes the PIC code run. MC/ARM/elf-movt.s covers this case. llvm-svn: 131674
2011-05-19 22:55:25 +02:00
@ ASM-NEXT: movt r0, :upper16:(GOT-(.LPC0_2+8))
Workaround for bug 8721. .s Test added. llvm-svn: 123292
2011-01-12 00:53:41 +01:00
1. Support ELF pcrel relocations for movw/movt: R_ARM_MOVT_PREL and R_ARM_MOVW_PREL_NC. 2. Fix minor bug in ARMAsmPrinter - treat bitfield flag as a bitfield, not an enum. 3. Add support for 3 new elf section types (no-ops) llvm-svn: 123294
2011-01-12 01:19:25 +01:00
@@ make sure that the text section fixups are sane too
@ OBJ: '.text'
@ OBJ-NEXT: 'sh_type', 0x00000001
@ OBJ-NEXT: 'sh_flags', 0x00000006
@ OBJ-NEXT: 'sh_addr', 0x00000000
@ OBJ-NEXT: 'sh_offset', 0x00000034
@ OBJ-NEXT: 'sh_size', 0x00000008
@ OBJ-NEXT: 'sh_link', 0x00000000
@ OBJ-NEXT: 'sh_info', 0x00000000
@ OBJ-NEXT: 'sh_addralign', 0x00000004
@ OBJ-NEXT: 'sh_entsize', 0x00000000
This fixes one divergence between LLVM and binutils for ARM in the text section. Assume the following bit of annotated assembly: .section .data.rel.ro,"aw",%progbits .align 2 .LAlpha: .long startval(GOTOFF) .text .align 2 .type main,%function .align 4 main: ;;; assume "main" starts at offset 0x20 0x0 push {r11, lr} 0x4 movw r0, :lower16:(.LAlpha-(.LBeta+8)) ;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8) ;;; ==> (??? - ((16-4) + 8) = -20 0x8 movt r0, :upper16:(.LAlpha-(.LBeta+8)) ;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8) ;;; ==> (??? - ((16-8) + 8) = -16 0xc ... blah .LBeta: 0x10 add r0, pc, r0 0x14 ... blah .LGamma: 0x18 add r1, pc, r1 Above snippet results in the following relocs in the .o file for the first pair of movw/movt instructions 00000024 R_ARM_MOVW_PREL_NC .LAlpha 00000028 R_ARM_MOVT_PREL .LAlpha And the encoded instructions in the .o file for main: must be 00000020 <main>: 20: e92d4800 push {fp, lr} 24: e30f0fec movw r0, #65516 ; 0xffec i.e. -20 28: e34f0ff0 movt r0, #65520 ; 0xfff0 i.e. -16 However, llc (prior to this commit) generates the following sequence 00000020 <main>: 20: e92d4800 push {fp, lr} 24: e30f0fec movw r0, #65516 ; 0xffec - i.e. -20 28: e34f0fff movt r0, #65535 ; 0xffff - i.e. -1 What has to happen in the ArmAsmBackend is that if the relocation is PC relative, the 16 bits encoded as part of movw and movt must be both addends, not addresses. It makes sense to encode addresses by right shifting the value by 16, but the result is incorrect for PIC. i.e., the right shift by 16 for movt is ONLY valid for the NON-PCRel case. This change agrees with what GNU as does, and makes the PIC code run. MC/ARM/elf-movt.s covers this case. llvm-svn: 131674
2011-05-19 22:55:25 +02:00
@ OBJ-NEXT: '_section_data', 'f00f0fe3 f40f4fe3'
1. Support ELF pcrel relocations for movw/movt: R_ARM_MOVT_PREL and R_ARM_MOVW_PREL_NC. 2. Fix minor bug in ARMAsmPrinter - treat bitfield flag as a bitfield, not an enum. 3. Add support for 3 new elf section types (no-ops) llvm-svn: 123294
2011-01-12 01:19:25 +01:00
@ OBJ: Relocation 0x00000000
@ OBJ-NEXT: 'r_offset', 0x00000000
@ OBJ-NEXT: 'r_sym'
@ OBJ-NEXT: 'r_type', 0x0000002d
@ OBJ: Relocation 0x00000001
@ OBJ-NEXT: 'r_offset', 0x00000004
@ OBJ-NEXT: 'r_sym'
@ OBJ-NEXT: 'r_type', 0x0000002e
Reference in New Issue Copy Permalink