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
68e194ce22
llvm-mirror/test/MC/ELF/alias.s

86 lines
2.7 KiB
ArmAsm
Raw Normal View History

Implement a simple alias case and refactor the code a bit so that the isInSymtab and isLocal logic in the two loops don't get easily out of sync. llvm-svn: 115643
2010-10-05 20:01:23 +02:00
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | elf-dump | FileCheck %s
foo:
bar = foo
Implement more alias cases. llvm-svn: 115699
2010-10-06 00:26:43 +02:00
.globl foo2
foo2 = bar2
foo3:
.globl bar3
bar3 = foo3
Get binding and visibility info from the the alias, but Type from the symbol being aliased. llvm-svn: 115836
2010-10-06 23:02:29 +02:00
// Test that bar4 is also a function
.type foo4,@function
foo4:
bar4 = foo4
Be more strict on when we produce an undefined reference. In gas a file with just .type foo,@object will produce an undefined reference to foo. On the other hand, a file with just .weakref bar, foo will not. It is somewhat hard to support both in MC since both statements should create the symbols. It should be possible if we really need to by adding to the flags, but hopefully that is not necessary. With this patch we do not produce a undefined reference in any of those cases. The assembly file needs an actual use for the undefined reference to be present. This is in preparation for a patch implementing .weakref. llvm-svn: 117735
2010-10-30 01:09:31 +02:00
.long foo2
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK: # 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: (('st_name', 0x00000005) # 'bar'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x0)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x0)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0001)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Implement a simple alias case and refactor the code a bit so that the isInSymtab and isLocal logic in the two loops don't get easily out of sync. llvm-svn: 115643
2010-10-05 20:01:23 +02:00
// CHECK-NEXT: ),
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK-NEXT: # 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: (('st_name', 0x0000001d) # 'bar4'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x0)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x2)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0001)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Get binding and visibility info from the the alias, but Type from the symbol being aliased. llvm-svn: 115836
2010-10-06 23:02:29 +02:00
// CHECK-NEXT: ),
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK-NEXT: # Symbol 3
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: (('st_name', 0x00000001) # 'foo'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x0)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x0)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0001)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Get binding and visibility info from the the alias, but Type from the symbol being aliased. llvm-svn: 115836
2010-10-06 23:02:29 +02:00
// CHECK-NEXT: ),
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK-NEXT: # Symbol 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-NEXT: (('st_name', 0x0000000e) # 'foo3'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x0)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x0)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0001)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Get binding and visibility info from the the alias, but Type from the symbol being aliased. llvm-svn: 115836
2010-10-06 23:02:29 +02:00
// CHECK-NEXT: ),
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK-NEXT: # Symbol 5
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: (('st_name', 0x00000018) # 'foo4'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x0)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x2)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0001)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Get binding and visibility info from the the alias, but Type from the symbol being aliased. llvm-svn: 115836
2010-10-06 23:02:29 +02:00
// CHECK-NEXT: ),
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK-NEXT: # 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: (('st_name', 0x00000000) # ''
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK: # Symbol 7
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: (('st_name', 0x00000000) # ''
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK: # 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: (('st_name', 0x00000000) # ''
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK: # Symbol 9
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: (('st_name', 0x00000013) # 'bar3'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x1)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x0)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0001)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Another counter goes decimal. llvm-svn: 136871
2011-08-04 16:27:46 +02:00
// CHECK: # Symbol 10
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: (('st_name', 0x00000009) # 'bar2'
Print st_bind with the correct number of bits. llvm-svn: 136874
2011-08-04 17:10:35 +02:00
// CHECK-NEXT: ('st_bind', 0x1)
print st_type with the correct number of bits. llvm-svn: 136875
2011-08-04 17:24:00 +02:00
// CHECK-NEXT: ('st_type', 0x0)
print st_other with the correct number of bits. llvm-svn: 136877
2011-08-04 17:38:19 +02:00
// CHECK-NEXT: ('st_other', 0x00)
print st_shndx with the correct number of bits. llvm-svn: 136880
2011-08-04 17:50:13 +02:00
// CHECK-NEXT: ('st_shndx', 0x0000)
Print all 64bits for st_value and st_size. Adjust tests accordingly. llvm-svn: 122263
2010-12-20 21:49:43 +01:00
// CHECK-NEXT: ('st_value', 0x0000000000000000)
// CHECK-NEXT: ('st_size', 0x0000000000000000)
Reference in New Issue Copy Permalink