6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-11-16 11:05:54 +00:00
Code Issues Projects Releases Wiki Activity
cbf68dfbc0
llvm-6502/test/MC/ELF/align-nops.s

41 lines
1.2 KiB
ArmAsm
Raw Normal View History

Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +00:00
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | elf-dump --dump-section-data | FileCheck %s
// Test that we get optimal nops in text
.text
f0:
.long 0
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
.align 8, 0x00000090
Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +00:00
.long 0
.align 8
// But not in another section
.data
.long 0
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
.align 8, 0x00000090
Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +00:00
.long 0
.align 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. 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: (('sh_name', 0x00000001) # '.text'
// CHECK-NEXT: ('sh_type', 0x00000001)
// CHECK-NEXT: ('sh_flags', 0x00000006)
Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +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)
// CHECK-NEXT: ('sh_link', 0x00000000)
// CHECK-NEXT: ('sh_info', 0x00000000)
// CHECK-NEXT: ('sh_addralign', 0x00000008)
// CHECK-NEXT: ('sh_entsize', 0x00000000)
Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +00:00
// CHECK-NEXT: ('_section_data', '00000000 0f1f4000 00000000 0f1f4000')
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: (('sh_name', 0x00000007) # '.data'
// CHECK-NEXT: ('sh_type', 0x00000001)
// CHECK-NEXT: ('sh_flags', 0x00000003)
Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +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)
// CHECK-NEXT: ('sh_link', 0x00000000)
// CHECK-NEXT: ('sh_info', 0x00000000)
// CHECK-NEXT: ('sh_addralign', 0x00000008)
// CHECK-NEXT: ('sh_entsize', 0x00000000)
Add hook in MCSection to decide when to use "optimized nops", for each section kind. Previously, optimized nops were only used for MachO. Also added tests for ELF and COFF. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115523 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-04 17:32:41 +00:00
// CHECK-NEXT: ('_section_data', '00000000 90909090 00000000 00000000')
Reference in New Issue Copy Permalink