6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-18 10:31:57 +00:00
Code Issues Projects Releases Wiki Activity
5adfba283d
llvm-6502/test/MC/ELF/entsize.s

70 lines
2.0 KiB
ArmAsm
Raw Normal View History

Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | elf-dump --dump-section-data | FileCheck %s
// Test that mergeable constants have sh_entsize set.
// 1 byte strings
.section .rodata.str1.1,"aMS",@progbits,1
.type .L.str1,@object # @.str1
.L.str1:
.asciz "tring"
.size .L.str1, 6
.type .L.str2,@object # @.str2
.L.str2:
.asciz "String"
.size .L.str2, 7
// 2 byte strings
.section .rodata.str2.1,"aMS",@progbits,2
.type .L.str3,@object # @.str3
.L.str3:
.asciz "L\000o\000n\000g\000"
.size .L.str3, 9
.type .L.str4,@object # @.str4
.L.str4:
.asciz "o\000n\000g\000"
.size .L.str4, 7
// 8 byte constants
.section .rodata.cst8,"aM",@progbits,8
.quad 42
.quad 42
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 0x00000004
Update tests git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129116 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-07 23:51:25 +00:00
// CHECK-NEXT: ('sh_name', 0x00000048) # '.rodata.str1.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. 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-NEXT: ('sh_type', 0x00000001)
// CHECK-NEXT: ('sh_flags', 0x00000032)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// CHECK-NEXT: ('sh_addr',
// CHECK-NEXT: ('sh_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. 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-NEXT: ('sh_size', 0x0000000d)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// CHECK-NEXT: ('sh_link',
// CHECK-NEXT: ('sh_info',
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-NEXT: ('sh_addralign', 0x00000001)
// CHECK-NEXT: ('sh_entsize', 0x00000001)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +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 0x00000005
Update tests git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129116 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-07 23:51:25 +00:00
// CHECK-NEXT: ('sh_name', 0x00000039) # '.rodata.str2.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. 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-NEXT: ('sh_type', 0x00000001)
// CHECK-NEXT: ('sh_flags', 0x00000032)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// CHECK-NEXT: ('sh_addr',
// CHECK-NEXT: ('sh_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. 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-NEXT: ('sh_size', 0x00000010)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// CHECK-NEXT: ('sh_link',
// CHECK-NEXT: ('sh_info',
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-NEXT: ('sh_addralign', 0x00000001)
// CHECK-NEXT: ('sh_entsize', 0x00000002)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +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 0x00000006
Update tests git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129116 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-07 23:51:25 +00:00
// CHECK-NEXT: ('sh_name', 0x0000002c) # '.rodata.cst8
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-NEXT: ('sh_type', 0x00000001)
// CHECK-NEXT: ('sh_flags', 0x00000012)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// CHECK-NEXT: ('sh_addr',
// CHECK-NEXT: ('sh_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. 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-NEXT: ('sh_size', 0x00000010)
Have ELFAsmParser.cpp use the already parsed "Size" (entry size) when constructing a section. Test for a few cases also included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115132 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 02:41:46 +00:00
// CHECK-NEXT: ('sh_link',
// CHECK-NEXT: ('sh_info',
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-NEXT: ('sh_addralign', 0x00000001)
// CHECK-NEXT: ('sh_entsize', 0x00000008)
Reference in New Issue Copy Permalink