mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 18:54:02 +01:00
5661b7eb80
This extends any frame record created in the function to include that parameter, passed in X22. The new record looks like [X22, FP, LR] in memory, and FP is stored with 0b0001 in bits 63:60 (CodeGen assumes they are 0b0000 in normal operation). The effect of this is that tools walking the stack should expect to see one of three values there: * 0b0000 => a normal, non-extended record with just [FP, LR] * 0b0001 => the extended record [X22, FP, LR] * 0b1111 => kernel space, and a non-extended record. All other values are currently reserved. If compiling for arm64e this context pointer is address-discriminated with the discriminator 0xc31a and the DB (process-specific) key. There is also an "i8** @llvm.swift.async.context.addr()" intrinsic providing front-ends access to this slot (and forcing its creation initialized to nullptr if necessary).
14 lines
609 B
LLVM
14 lines
609 B
LLVM
; RUN: llc -mtriple=arm64-apple-ios %s -filetype=obj -o - | llvm-objdump --unwind-info - | FileCheck %s
|
|
|
|
; Swift asynchronous context is incompatible with the compact unwind encoding
|
|
; that currently exists and assumes callee-saved registers are right next to FP
|
|
; in a particular order. This isn't a problem now because C++ exceptions aren't
|
|
; allowed to unwind through Swift code, but at least make sure the compact info
|
|
; says to use DWARF correctly.
|
|
|
|
; CHECK: compact encoding: 0x03000000
|
|
define void @foo(i8* swiftasync %in) "frame-pointer"="all" {
|
|
call void asm sideeffect "", "~{x23}"()
|
|
ret void
|
|
}
|