LLDB currently has special extended frame support for Swift async frames for x86_64 and arm64. Unfortunately, it doesn't work correctly with windows x86_64 frame layout, as it makes an assumption that the previous frame pointer is stored right at the current frame pointer address, which is not guaranteed to be the case on windows. Also, the LLVM code generator had a bug related to the use of frame pointer - 8 stack slot for the async frame context pointer, so we now decided to use a regular stack slot allocation to store the async frame context pointer: [x86_64][windows][swift] do not use Swift async extended frame for wi… by hyp · Pull Request #80468 · llvm/llvm-project · GitHub . This is also what LLVM uses for x32, but AFAIK LLDB doesn't handle this case.
Is there a good way to teach LLDB that a specific stack slot is used as a place where the async context pointer is stored, instead of it assuming it's at frame pointer - 8?
I think that it is just a matter of updating the
GetFollowAsyncContextUnwindPlan based upon the current selected target platform.
That's definitely the right place to start looking. There are probably opportunities to modularize the existing code some more as we add more platforms.
Thanks! I was wondering if you have any insight into what's the best representation format for storing the stack offset of the stored async frame pointer. Can something like DWARF work for it?
Yes, DWARF should be able to represent that. Worst case scenario, we will need to add a vendor extension to the encoding to indicate that storage. However, I think that the most generic way to represent this may be a register spill and having LLDB analyze the stack frame to realize it is an async frame where it needs to reconstruct the register state for the async context. Not exactly clean, but would be generic and would allow better interoperability with other debuggers.
If the offset isn't fixed and you want to encode it in DWARF, the way to do this is to emit debug info for an artificial variable (e.g., "$swift_async_frame") whose location points to it.