_Unwind_ForcedUnwind is not mandated by the EHABI but for compatibilty
reasons adding so the interface to higher layers would be the same.
We tested this patch in Chrome OS and it resolved our build issues :) . We do have issues on ARM32 with some crashes but we believe that is a separate problem. And we'll continue to look into those.
But I feel it should be ok for you to submit this or request a review from more qualified folks.
@manojgupta Thanks for the feedback, let me know if you have updates.
Because there was no forceunwind and only in that case the reserved1 is written.
|46 ↗||(On Diff #298857)|
done already in upstream.
@MaskRay Thanks for the test case.
The personality handling is a bit different. Might not be much nicer with that many ifdefs.
It passes now.
(Why does ARMEH uses a typedef so that struct _Unwind_Exception* does not compile? )
I think the original typedef struct _Unwind_Control_Block comes from the spec:
_Unwind_Control_Block could be just _Unwind_Exception.
IMHO there is no nice way to achieve the struct _Unwind_Exception* compile.
What's the issue that this solves?
splitting hairs, but should long here be intptr_t?
might be more clear to combine with if/else chain below and not rely on the PRIVATE_1 => private_1 => private_ expansion.
IIRC this needs special handling on baremetal, since there is no dladdr there.
Sorry, do you mean the content of the libunwind/include/unwind.h ?
struct _Unwind_Exception* is used mostly but the definition of _Unwind_Control_Block comes from the Arm EHABI. with the typedef struct _Unwind_Exception* won't work.
right, will fix.
agree, I'll update it.
for now I add a filter for the test it should run only on linux as other tests here.
I mean all the #if defined(_LIBCXXABI_ARM_EHABI) branches make the file difficult to read. reduce sharing and move the implementation to a separate file.
Many sanitizer files are organized this way.