6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-08-04 07:29:20 +00:00
Code Issues Projects Releases Wiki Activity
83ff4d2b0d
llvm-6502/test/MC/ELF/relocation.s

58 lines
1.8 KiB
ArmAsm
Raw Normal View History

Produce a R_X86_64_32 when the value is >=0. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114339 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-20 19:20:47 +00:00
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | elf-dump --dump-section-data | FileCheck %s
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// Test that we produce a R_X86_64_32S or R_X86_64_32.
Produce a R_X86_64_32 when the value is >=0. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114339 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-20 19:20:47 +00:00
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
bar:
movl $bar, %edx // R_X86_64_32
movq $bar, %rdx // R_X86_64_32S
movq $bar, bar(%rip) // R_X86_64_32S
movl bar, %edx // R_X86_64_32S
movq bar, %rdx // R_X86_64_32S
.long bar // R_X86_64_32
Produce a R_X86_64_32 when the value is >=0. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114339 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-20 19:20:47 +00:00
Fixing r116753 r116756 r116777 The failures in r116753 r116756 were caused by a python issue - Python likes to append 'L' suffix to stringified numbers if the number is larger than a machine int. Unfortunately, this causes a divergence of behavior between 32 and 64 bit python versions. I re-crafted elf-dump/common_dump to take care of these issues by: 1. always printing 0x (makes for easy sed/regex) 2. always print fixed length (exactly 2 + numBits/4 digits long) by mod ((2^numBits) - 1) 3. left-padded with '0' There is a residual common routine that is also used by macho-dump (dataToHex) , so I left the 'section_data' test values alone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:39:10 +00:00
// CHECK: # Section 0x00000001
// CHECK: (('sh_name', 0x00000001) # '.text'
// CHECK: # Symbol 0x00000002
// CHECK: (('st_name', 0x00000000) # ''
// CHECK: ('st_bind', 0x00000000)
// CHECK ('st_type', 0x00000003)
// CHECK: ('st_other', 0x00000000)
// CHECK: ('st_shndx', 0x00000001)
// CHECK: # Relocation 0x00000000
// CHECK-NEXT: (('r_offset', 0x00000001)
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x0000000a)
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// CHECK-NEXT: ('r_addend',
Fixing r116753 r116756 r116777 The failures in r116753 r116756 were caused by a python issue - Python likes to append 'L' suffix to stringified numbers if the number is larger than a machine int. Unfortunately, this causes a divergence of behavior between 32 and 64 bit python versions. I re-crafted elf-dump/common_dump to take care of these issues by: 1. always printing 0x (makes for easy sed/regex) 2. always print fixed length (exactly 2 + numBits/4 digits long) by mod ((2^numBits) - 1) 3. left-padded with '0' There is a residual common routine that is also used by macho-dump (dataToHex) , so I left the 'section_data' test values alone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:39:10 +00:00
// CHECK: # Relocation 0x00000001
// CHECK-NEXT: (('r_offset', 0x00000008)
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x0000000b)
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// CHECK-NEXT: ('r_addend',
Fixing r116753 r116756 r116777 The failures in r116753 r116756 were caused by a python issue - Python likes to append 'L' suffix to stringified numbers if the number is larger than a machine int. Unfortunately, this causes a divergence of behavior between 32 and 64 bit python versions. I re-crafted elf-dump/common_dump to take care of these issues by: 1. always printing 0x (makes for easy sed/regex) 2. always print fixed length (exactly 2 + numBits/4 digits long) by mod ((2^numBits) - 1) 3. left-padded with '0' There is a residual common routine that is also used by macho-dump (dataToHex) , so I left the 'section_data' test values alone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:39:10 +00:00
// CHECK: # Relocation 0x00000002
// CHECK-NEXT: (('r_offset', 0x00000013)
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x0000000b)
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// CHECK-NEXT: ('r_addend',
Fixing r116753 r116756 r116777 The failures in r116753 r116756 were caused by a python issue - Python likes to append 'L' suffix to stringified numbers if the number is larger than a machine int. Unfortunately, this causes a divergence of behavior between 32 and 64 bit python versions. I re-crafted elf-dump/common_dump to take care of these issues by: 1. always printing 0x (makes for easy sed/regex) 2. always print fixed length (exactly 2 + numBits/4 digits long) by mod ((2^numBits) - 1) 3. left-padded with '0' There is a residual common routine that is also used by macho-dump (dataToHex) , so I left the 'section_data' test values alone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:39:10 +00:00
// CHECK: # Relocation 0x00000003
// CHECK-NEXT: (('r_offset', 0x0000001a)
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x0000000b)
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// CHECK-NEXT: ('r_addend',
Fixing r116753 r116756 r116777 The failures in r116753 r116756 were caused by a python issue - Python likes to append 'L' suffix to stringified numbers if the number is larger than a machine int. Unfortunately, this causes a divergence of behavior between 32 and 64 bit python versions. I re-crafted elf-dump/common_dump to take care of these issues by: 1. always printing 0x (makes for easy sed/regex) 2. always print fixed length (exactly 2 + numBits/4 digits long) by mod ((2^numBits) - 1) 3. left-padded with '0' There is a residual common routine that is also used by macho-dump (dataToHex) , so I left the 'section_data' test values alone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:39:10 +00:00
// CHECK: # Relocation 0x00000004
// CHECK-NEXT: (('r_offset', 0x00000022)
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x0000000b)
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// CHECK-NEXT: ('r_addend',
Fixing r116753 r116756 r116777 The failures in r116753 r116756 were caused by a python issue - Python likes to append 'L' suffix to stringified numbers if the number is larger than a machine int. Unfortunately, this causes a divergence of behavior between 32 and 64 bit python versions. I re-crafted elf-dump/common_dump to take care of these issues by: 1. always printing 0x (makes for easy sed/regex) 2. always print fixed length (exactly 2 + numBits/4 digits long) by mod ((2^numBits) - 1) 3. left-padded with '0' There is a residual common routine that is also used by macho-dump (dataToHex) , so I left the 'section_data' test values alone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:39:10 +00:00
// CHECK: # Relocation 0x00000005
// CHECK-NEXT: (('r_offset', 0x00000026)
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x0000000a)
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115134 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 03:11:42 +00:00
// CHECK-NEXT: ('r_addend',
Reference in New Issue Copy Permalink