You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[x86_64][windows][swift] do not use Swift async extended frame for windows x86_64
targets that use windows 64 prologue
Windows x86_64 stack frame layout is currently not compatible with Swift's async extended
frame, which reserves the slot right below RBP (RBP-8) for the async context
pointer, as it doesn't account for the fact that a stack object in a win64 frame can
be allocated at the same location. This can cause issues at runtime, for instance, Swift's
TCA test code has functions that fail because of this issue, as they spill a value to that
slack slot, which then gets overwritten by a store into address returned by the
@llvm.swift.async.context.addr() intrinsic (that ends up being RBP - 8), leading to an
incorrect value being used at a later point when that stack slot is being read from again.
This change drops the use of async extended frame for windows x86_64 subtargets and
instead uses the x32 based approach of allocating a separate stack slot for the stored
async context pointer.
Additionally, LLDB which is the primary consumer of the extended frame makes assumptions
like checking for a saved previous frame pointer at the current frame pointer address,
which is also incompatible with the windows x86_64 frame layout, as the previous frame
pointer is not guaranteed to be stored at the current frame pointer address. Therefore
the extended frame layout can be turned off to fix the current miscompile without
introducing regression into LLDB for windows x86_64 as it already doesn't work correctly.
I am still investigating what should be made for LLDB to support using an allocated
stack slot to store the async frame context instead of being located at RBP - 8 for
windows.
0 commit comments