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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
