Sub sp,sp,#outsz // (optional for #outsz != 0)Ĭhained, #localsz > 512 stp x19,x20,! // pre-indexed, save in 1st FP/INT pair Mov x29,sp // x29 points to bottom of local #localsz and #outsz denote local area size (including the save area for the pair) and outgoing parameter size, respectively.Ĭhained, #localsz at bottom of local area #framesz below represents the size of entire stack (excluding alloca area). For the sake of clarity and better cache locality, the order of storing callee-saved registers in all canonical prologs is in "growing up" order. Here are examples that illustrate several of the most efficient prolog sequences. To allow for better register-pair-addressing-mode coverage, nonvolatile register save areas are positioned at the top of the Local area stack. However, for alloca functions, it must be chained, and x29 must point to the bottom of stack. The goal is to maximize the number of locals that can be reached by a single instruction based on the frame pointer ( x29) or stack pointer ( sp). The stack frame layout is organized as described in the next section.įor frame chained functions, the fp and lr pair can be saved at any position in the local variable area, depending on optimization considerations. Unless the sp is saved in another register, all manipulation of the stack pointer occurs strictly within the prolog and epilog. It means the original sp may be recovered at any time. Several optimizations for space rely on this fact to achieve the most efficient packing of data.ĭedicated frame pointer register: If the sp is saved in another register ( x29) in the prolog, that register remains untouched throughout the function. Both should produce identical results.įunctions tend on the whole to be relatively small. Within the body of the function, it doesn't matter whether the prolog's operations are undone, or the epilog's operations are done in a forward manner. By taking advantage of this common trait, the size of the metadata needed to describe unwinding can be greatly reduced. Prologs and epilogs tend to mirror each other. These assumptions are made in the exception handling description: Since the unwind codes are likely to be locked in memory, a small footprint ensures a minimal overhead for each loaded binary. The unwind codes must not aggregate to significantly increase the binary size. It's critical that code can unwind accurately even when in the middle of a prolog or epilog code sequence. Unwinding is used in Windows for more than exception handling.Support unwinding in mid-prolog and mid-epilog. Instruction decoding increases the overall complexity, and ideally should be avoided. If unwinding can't be fully described by using unwind codes, then in some cases it must fall back to instruction decoding. It prevents unwinding in some circumstances where it's useful (tracing, sampling, debugging).Īnalyzing the code is complex the compiler must be careful to only generate instructions that the unwinder can decode. Provide enough description to allow unwinding without code probing in all cases.Īnalyzing the code requires the code to be paged in. The exception unwinding data conventions, and this description, are intended to: It illustrates the language helpers used by code that's generated by the Microsoft ARM assembler and the MSVC compiler. This document describes exception handling in Windows on ARM64. Language-specific exception handlers are built on top of Windows structured exception handling by using language helper functions. Windows on ARM64 uses the same structured exception handling mechanism for asynchronous hardware-generated exceptions and synchronous software-generated exceptions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |