RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2024-12-21 11:38:35 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
e186d7191c
llvm/test/MC/MachO/relax-recompute-align.s

38 lines
1.1 KiB
ArmAsm
Raw Normal View History

MC/Mach-O: Implement initial support for relaxation. - The implementation is currently very brain dead and inefficient, but I have a clear plan on how to fix it. - The good news is, it works and correctly assembles 403.gcc (when built with Clang, at '-Os', '-Os -g', and '-O3'). Even better, at '-Os' and '-Os -g', the resulting binary is exactly equivalent to that when built with the system assembler. So it probably works! :) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98396 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-12 22:07:14 +00:00
// RUN: llvm-mc -triple i386-apple-darwin9 %s -filetype=obj -o - | macho-dump --dump-section-data | FileCheck %s
// FIXME: This is a horrible way of checking the output, we need an llvm-mc
// based 'otool'.
Relax alignment fragments. With this we don't need the EffectiveSize field anymore. Without that field LayoutFragment only updates offsets and we don't need to invalidate the current fragment when it is relaxed (only the ones following it). This is also a very small improvement in the accuracy of the layout info as we now use the after relaxation size immediately. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121857 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-15 08:45:53 +00:00
// This is a case where llvm-mc computes a better layout than Darwin 'as'. This
// issue is that after the first jmp slides, the .align size must be
// recomputed -- otherwise the second jump will appear to be out-of-range for a
// 1-byte jump.
MC/Mach-O: Implement initial support for relaxation. - The implementation is currently very brain dead and inefficient, but I have a clear plan on how to fix it. - The good news is, it works and correctly assembles 403.gcc (when built with Clang, at '-Os', '-Os -g', and '-O3'). Even better, at '-Os' and '-Os -g', the resulting binary is exactly equivalent to that when built with the system assembler. So it probably works! :) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98396 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-12 22:07:14 +00:00
// CHECK: # Section 0
// CHECK: (('section_name', '__text\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
// CHECK: ('segment_name', '__TEXT\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
// CHECK: ('address', 0)
Relax alignment fragments. With this we don't need the EffectiveSize field anymore. Without that field LayoutFragment only updates offsets and we don't need to invalidate the current fragment when it is relaxed (only the ones following it). This is also a very small improvement in the accuracy of the layout info as we now use the after relaxation size immediately. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121857 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-15 08:45:53 +00:00
// CHECK: ('size', 306)
MC/Mach-O: Implement initial support for relaxation. - The implementation is currently very brain dead and inefficient, but I have a clear plan on how to fix it. - The good news is, it works and correctly assembles 403.gcc (when built with Clang, at '-Os', '-Os -g', and '-O3'). Even better, at '-Os' and '-Os -g', the resulting binary is exactly equivalent to that when built with the system assembler. So it probably works! :) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98396 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-12 22:07:14 +00:00
// CHECK: ('offset', 324)
// CHECK: ('alignment', 4)
// CHECK: ('reloc_offset', 0)
// CHECK: ('num_reloc', 0)
// CHECK: ('flags', 0x80000400)
// CHECK: ('reserved1', 0)
// CHECK: ('reserved2', 0)
// CHECK: ),
L0:
.space 0x8a, 0x90
jmp L0
.space (0xb3 - 0x8f), 0x90
jle L2
.space (0xcd - 0xb5), 0x90
.align 4, 0x90
L1:
.space (0x130 - 0xd0),0x90
jl L1
L2:
.zerofill __DATA,__bss,_sym,4,2
Reference in New Issue Copy Permalink