RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-02 00:42:52 +01:00
Code Issues Projects Releases Wiki Activity
4e6d375744
llvm-mirror/test/MC/ELF/merge.s

98 lines
2.8 KiB
ArmAsm
Raw Normal View History

Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | elf-dump --dump-section-data | FileCheck %s
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// Test that PIC relocations with local symbols in a mergeable section are done
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
// with a reference to the symbol. Not sure if this is a linker limitation,
// but this matches the behavior of gas.
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// Non-PIC relocations with 0 offset don't use the symbol.
movsd .Lfoo(%rip), %xmm1
movl $.Lfoo, %edi
movl $.Lfoo+2, %edi
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
jmp foo@PLT
Correctly handle GOTPCREL relocations. llvm-svn: 115793
2010-10-06 18:23:36 +02:00
movq foo@GOTPCREL, %rax
If a symbol is global, reloc against it even if it is in a mergeable section. llvm-svn: 115817
2010-10-06 21:27:21 +02:00
movq zed, %rax
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
.section .sec1,"aM",@progbits,16
.Lfoo:
If a symbol is global, reloc against it even if it is in a mergeable section. llvm-svn: 115817
2010-10-06 21:27:21 +02:00
zed:
.global zed
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
.section bar,"ax",@progbits
foo:
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// Section 4 is "sec1"
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK: # Section 0x00000004
// CHECK-NEXT: (('sh_name', 0x00000012) # '.sec1'
Write relocations in the end of the file. This matches what gas does and makes files easier to diff. llvm-svn: 114898
2010-09-28 00:04:54 +02:00
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// Symbol number 1 is .Lfoo
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK: # Symbol 0x00000001
// CHECK-NEXT: (('st_name', 0x00000001) # '.Lfoo'
Write relocations in the end of the file. This matches what gas does and makes files easier to diff. llvm-svn: 114898
2010-09-28 00:04:54 +02:00
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
// Symbol number 2 is foo
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK: # Symbol 0x00000002
// CHECK-NEXT: (('st_name', 0x00000007) # 'foo'
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
// Symbol number 6 is section 4
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK: # Symbol 0x00000006
// CHECK-NEXT: (('st_name', 0x00000000) # ''
// CHECK-NEXT: ('st_bind', 0x00000000)
// CHECK-NEXT: ('st_type', 0x00000003)
// CHECK-NEXT: ('st_other', 0x00000000)
// CHECK-NEXT: ('st_shndx', 0x00000004)
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
If a symbol is global, reloc against it even if it is in a mergeable section. llvm-svn: 115817
2010-10-06 21:27:21 +02:00
// Symbol number 8 is zed
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK: # Symbol 0x00000008
// CHECK-NEXT: (('st_name', 0x0000000b) # 'zed'
If a symbol is global, reloc against it even if it is in a mergeable section. llvm-svn: 115817
2010-10-06 21:27:21 +02:00
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// Relocation 0 refers to symbol 1
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
// CHECK: ('_relocations', [
// CHECK-NEXT: # Relocation 0
// CHECK-NEXT: (('r_offset',
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: ('r_sym', 0x00000001)
// CHECK-NEXT: ('r_type', 0x00000002
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// CHECK-NEXT: ('r_addend',
// CHECK-NEXT: ),
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
// Relocation 1 refers to symbol 6
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: # Relocation 0x00000001
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// CHECK-NEXT: (('r_offset',
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: ('r_sym', 0x00000006)
// CHECK-NEXT: ('r_type', 0x0000000a)
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// CHECK-NEXT: ('r_addend',
// CHECK-NEXT: ),
// Relocation 2 refers to symbol 1
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: # Relocation 0x00000002
Tests that now pass. llvm-svn: 115622
2010-10-05 17:43:32 +02:00
// CHECK-NEXT: (('r_offset',
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: ('r_sym', 0x00000001)
// CHECK-NEXT: ('r_type', 0x0000000a
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
// CHECK-NEXT: ('r_addend',
// CHECK-NEXT: ),
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
// Relocation 3 refers to symbol 2
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: # Relocation 0x00000003
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
// CHECK-NEXT: (('r_offset',
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x00000004
Use a relocation against the symbol if it is a PLT and the symbol is in another section. Common because of linkonce sections. llvm-svn: 115718
2010-10-06 01:57:26 +02:00
// CHECK-NEXT: ('r_addend',
// CHECK-NEXT: ),
Correctly handle GOTPCREL relocations. llvm-svn: 115793
2010-10-06 18:23:36 +02:00
// Relocation 4 refers to symbol 2
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: # Relocation 0x00000004
Correctly handle GOTPCREL relocations. llvm-svn: 115793
2010-10-06 18:23:36 +02:00
// CHECK-NEXT: (('r_offset',
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: ('r_sym', 0x00000002)
// CHECK-NEXT: ('r_type', 0x00000009
Correctly handle GOTPCREL relocations. llvm-svn: 115793
2010-10-06 18:23:36 +02:00
// CHECK-NEXT: ('r_addend',
// CHECK-NEXT: ),
If a symbol is global, reloc against it even if it is in a mergeable section. llvm-svn: 115817
2010-10-06 21:27:21 +02:00
// Relocation 5 refers to symbol 8
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. llvm-svn: 116823
2010-10-19 19:39:10 +02:00
// CHECK-NEXT: # Relocation 0x00000005
// CHECK-NEXT: (('r_offset', 0x00000023)
// CHECK-NEXT: ('r_sym', 0x00000008)
// CHECK-NEXT: ('r_type', 0x0000000b)
// CHECK-NEXT: ('r_addend', 0x00000000)
If a symbol is global, reloc against it even if it is in a mergeable section. llvm-svn: 115817
2010-10-06 21:27:21 +02:00
// CHECK-NEXT: ),
Move ELF to HasReliableSymbolDifference=true. Also take the opportunity to put symbols defined in merge sections in independent atoms. llvm-svn: 114786
2010-09-25 07:42:19 +02:00
// CHECK-NEXT: ])
Reference in New Issue Copy Permalink