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 _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits