[PATCH] D38819: [libunwind] Add support for dwarf unwinding on windows on x86_64
Martin Storsjö via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Oct 23 14:36:44 PDT 2017
mstorsjo added inline comments.
Comment at: src/UnwindRegistersRestore.S:98
+ # skip fs
+ # skip gs
+ movq 56(%rcx), %rsp # cut back rsp to new location
> mstorsjo wrote:
> > mstorsjo wrote:
> > > compnerd wrote:
> > > > Doesn't Win64 ABI require some of the MMX registers be saved/restored too?
> > > Right, yes, xmm6-xmm15 should be backed up and restored. I'll try to amend this with such a change.
> > Actually, such a change doesn't necessarily make much sense on its own.
> > As long as the dwarf encoding itself doesn't describe how to restore those registers (and on unix platforms you don't need to, so it probably isn't even specified), you'd just end up backing up the xmm registers on entry when throwing the exception, and restoring the exactly same ones again - it only guards against changes within libcxxabi/libunwind and the unwinding machinery itself, not against changes further down in the call stack between the thrower and catcher of the exception.
> > So with that, I guess this patch is futile unless planning to extend the x86_64 dwarf handling in llvm to include those registers as well - and that's a little out of scope of what I intended to do here...
> If we have XMM values in the register context, we might as well reload them here. I assume libunwind will switch away from DWARF and over to UNWIND_INFO opcodes in the near future, and that will give us an accurate register context.
Yeah, although to do anything useful with the XMM registers, the llvm backend would have to output dwarf opcodes for callee saved xmm registers, which it currently doesn't. Otherwise it'll just reload them back to the same values as they already are. I've managed to hack LLVM to do that (without fully understanding what I'm doing though), and I'll see if I manage to update libunwind to use that as well.
More information about the cfe-commits