> On Oct 13, 2016, at 1:07 PM, Todd Fiala via swift-lldb-dev
> <firstname.lastname@example.org> wrote:
> I’m not entirely sure of all the places that care.
> * Possibly the unwinder, although that might not care since it needs to
> handle hand-rolled assembly and everything in between. Jason could say more
Having an alternate calling convention where a register changes from
callee-saved to an argument register does have a (somewhat small) impact on the
unwinder. The unwinder will only allow register values that are callee-saved
to be copied up through stack frames. If you're looking at frame #2 in a
backtrace and ask lldb for the contents of rbx (a callee-saved reg on x86_64
with the SysV ABI), lldb will look to see if frame 1 spilled the reg to the
stack. If it did not, then it will look if frame 0 spilled the reg to the
stack. If not, it will take the current value of rbx from frame 0 and print
that as the value for frame 2 because that register has not been used for
If rbx changes from callee-spilled to argument register for certain stack
frames, and the unwinder doesn't know that, then if you're in frame #2 and ask
lldb to print rbx, it will look for spills in frames 1 & 0, not find them, and
take the current value of rbx (which is likely modified since it was in frame
2) and present that to the user.
To handle this correctly, the unwinder would need a way to tell if a stack
frame (e.g. frame 1 in the above example) is using the alternate calling
convention (either DWARF or hardcoding it for all swift frames or something)
and not allow the register to be restored at that stack frame or any frame
> * Maybe the expression parser, if calling into methods with a new ABI? Sean
> could probably say more here.
>>>> This might have implications on the debugger.
>>>> My current plan is to finish the swift/llvm side of this work in the next
>>>> couple weeks. There is a prototype at
>>>> that can be tried out today.
>>>> There are two radars that track work related to lldb and dwarf support:
>>>> <rdar://problem/24489517> DWARF support for the new Swift calling
>>>> <rdar://problem/25471028> LLDB support for new Swift calling convention
>>>> swift-lldb-dev mailing list
>>> swift-lldb-dev mailing list
> swift-lldb-dev mailing list
swift-lldb-dev mailing list