[PATCH] D11190: unwind: Fix libc++abi and libgcc build.

[Saleem Abdulrasool]

compnerd added a comment.

Im not sure that this is the best way to handle this.  Currently, use of the savannah unwind would provide these interfaces on ARM.  I realize that the alternate implementation of unwind is not EHABI compliant, but that does make this slightly challenging.  Perhaps we could just provide a macro-like function which duplicates the interfaces, but bridges to _Unwind_VRS_{G,S}et.  (And, since Im sure you will ask, yes, I do have code which relies on these interfaces).


================
Comment at: include/unwind.h:224
@@ +223,3 @@
+
+static __inline__ uintptr_t _Unwind_GetGR(struct _Unwind_Context *context,
+                                          int index) {
----------------
logan wrote:
> asl wrote:
> > logan wrote:
> > > asl wrote:
> > > > Why can't we simply make them static functions of UnwindLevel1.c for EHABI case?
> > > They can't be //static// functions of UnwindLevel1.c because they will be called from the other source code (e.g. libc++abi calls these functions.)  If they are declared as static functions in UnwindLevel1.c, then the other source code can't access these functions.
> > > 
> > > We can't declare these functions as extern and define these functions in UnwindLevel1.c either.  If we do so, the source code including this header and using these functions will be compiled to object files with external symbols (undefined references) to these functions.  This means that these symbols should be available to the linkers.  However, libgcc does not provide these symbols.  If we are building libc++abi with libgcc without libunwinder, then we will encounter the following link error:
> > > 
> > >     libcxxabi/src/cxa_personality.cpp:(.text+0x3c): undefined reference to `_Unwind_SetGR'
> > >     (... and etc ...)
> > > 
> > > This is the reason why these functions must be inlined.  AFAICT, both the unwind.h from gcc or clang (`lib/Header/unwind.h`) are following the same practice.
> > I see. My biggest concern is the use of LIBCXXABI_ARM_EHABI define. We need to resolve this beforehand, because currently we're having a cyclic dependency between libunwind and libcxxabi via __cxxabi_config.h. I'd simply fold it inside libwunwind (or introduce __libunwind_config.h)
> OK.  I think I will simply copy the `ifdef`s from `__cxxabi_config.h` since they are simple.  Will update the patch soon.
> 
> My long term plan is to merge this `unwind.h` with the one in the clang repository.  And then, update libc++abi so that we can use the `unwind.h` from the compiler (both `clang` and `gcc`) directly.
The long term plan sounds great.  I think that is definitely the right direction.


http://reviews.llvm.org/D11190