This patch is generalization of D19920.
A new native-only libunwind variant (selectable through the -DLIBUNWIND_ENABLE_CROSS_UNWINDING=OFF cmake option) is introduced.
The sizes of Registers_xxx and the associated UnwindCursor<A, R> types are strictly matched against the sizes of unw_context_t and unw_cursor_t types defined in libunwind.h. This improves the stack usage of the unwinder as only just enough memory is reserved on the stack to hold the virtual register set on each architecture.
I've locally tested ARM, AArch64, x86 (compile-only) and x86_64 builds of the new variant. Could not perform any testing of PPC or OpenRISK as I couldn't get the cross compiling to work properly. Ideally, we'll have to switch the buildbots to use this new build option so that these strict limits will be validated (and will continue to be validated). This should be fine I think - if the library works for these restricted limits, the general case (which supports cross-unwinding) should follow.
If the patch is accepted, I will start a discussion on cfe-dev about switching the buildbot configurations (I'm assuming we don't have any cross-unwinding buildbot setups).
Wouldn't it be a lot simpler to just define a macro _LIBUNWIND_DATA_SIZE or something and have just one line here?