[PATCH] D86041: RFC [libunwind] Convert the register restore functions to C functions

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In D86041#2228770 <https://reviews.llvm.org/D86041#2228770>, @compnerd wrote:

> I think that the confusing part is that it is not that they are C functions, they are still assembly, but with C calling convention.  I think that you should state that in the description as it currently reads as though they are written in C, which they are not.

Ah, I see. Rephrasing:

[libunwind] Convert the register restore functions to C calling convention and name mangling

Currently, the assembly functions for restoring register state have been direct implementations of the Registers_*::jumpto() method (contrary to the functions for saving register state, which are implementations of the extern C function __unw_getcontext). This has included having the assembly function name match the C++ mangling of that method name (and having the function match the C++ member function calling convention). To simplify the interface of the assembly implementations, make the functions have C calling conventions and name mangling.

This fixes building the library in with a MSVC C++ ABI with clang-cl, which uses a significantly different method name mangling scheme. (The library might not be of much use as C++ exception unwinder in such an environment, but the libunwind.h interface for stepwise unwinding still is usable, as is the _Unwind_Backtrace function.)

> Right, there may need to be a thunk for some platforms but if the compiler does treat the call to the symbol as a tail call, that is fine.
>
> Can you share the reasoning for building libunwind with MSVC?  In particular, the calling convention isn't identical to the Unix calling convention, so you will need to use the Microsoft unwinder to get interoperability with MS ABI.

So for the actual calling convention, the existing assembly functions already have ifdefs so they work with the windows calling conventions for mingw.

Then for actual unwinding; libunwind, if operating in SEH mode, does call the Microsoft unwinder APIs, so it works in such an environment (just like it does in SEH mode for mingw). Most of the APIs from unwind.h doesn't make much sense to use there though (e.g. _Unwind_RaiseException and the related ones), but e.g. _Unwind_Backtrace should work just fine (just giving a callback for each stack frame), and the lower level libunwind.h APIs (unw_getcontext, unw_step, unw_get_reg etc) should work just fine.

If writing code from scratch for use on Windows, there'd be little point in using these instead of just calling the Microsoft unwinding APIs directly, but if porting user space code that already is calling these APIs on other platforms, it could make sense to use libunwind. That's the case that was posted on the llvm-dev list a few days ago.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86041/new/

https://reviews.llvm.org/D86041