> On Oct 13, 2016, at 1:07 PM, Todd Fiala via swift-lldb-dev > <swift-lldb-dev@swift.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 > here. 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 anything else. 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 after it. J > > * 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 >>>> https://github.com/aschwaighofer/swift/tree/native_calling_convention_wip >>>> 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 >>>> convention >>>> <rdar://problem/25471028> LLDB support for new Swift calling convention >>>> >>>> >>>> Best, >>>> Arnold >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-lldb-dev mailing list >>>> swift-lldb-dev@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev >>> >>> _______________________________________________ >>> swift-lldb-dev mailing list >>> swift-lldb-dev@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev >> > > _______________________________________________ > swift-lldb-dev mailing list > swift-lldb-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-lldb-dev _______________________________________________ swift-lldb-dev mailing list swift-lldb-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-lldb-dev
