Hi,
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?
6 posts - 3 participants