Bug 233664 - enable LLVM libunwind for armv7, armv6
Summary: enable LLVM libunwind for armv7, armv6
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Conrad Meyer
Keywords: feature
Depends on:
Blocks: 233094
  Show dependency treegraph
Reported: 2018-11-30 13:57 UTC by Ed Maste
Modified: 2019-11-08 16:15 UTC (History)
3 users (show)

See Also:
koobs: mfc-stable11-
koobs: mfc-stable12-


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2018-11-30 13:57:25 UTC
arm currently uses Clang and LLD, but LLVM_LIBUNWIND is not enabled.

For armv7 there are a couple of minor conflicts with other unwind helpers, and we need to update the symbol version map.  The hack below gets it to build, but needs to be cleaned up.

arm and armv6 fail with:
/.../arm.arm/tmp/usr/lib/libcxxrt.so: undefined reference to `__gnu_unwind_frame@GCC_3.5'
/.../arm.arm/tmp/usr/lib/libcxxrt.so: undefined reference to `_Unwind_VRS_Set@GCC_3.5'
/.../arm.arm/tmp/usr/lib/libcxxrt.so: undefined reference to `_Unwind_VRS_Get@GCC_3.5'

armv7 hack patch:

diff --git a/contrib/compiler-rt/lib/builtins/gcc_personality_v0.c b/contrib/compiler-rt/lib/builtins/gcc_personality_v0.c
index 0bc765624564..034d323814c4 100644
--- a/contrib/compiler-rt/lib/builtins/gcc_personality_v0.c
+++ b/contrib/compiler-rt/lib/builtins/gcc_personality_v0.c
@@ -145,6 +145,7 @@ static uintptr_t readEncodedPointer(const uint8_t** data, uint8_t encoding)
 #if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) &&                 \
 #define USING_ARM_EHABI 1
+struct _Unwind_Exception;
 _Unwind_Reason_Code __gnu_unwind_frame(struct _Unwind_Exception *,
                                        struct _Unwind_Context *);
diff --git a/contrib/compiler-rt/lib/builtins/unwind-ehabi-helpers.h b/contrib/compiler-rt/lib/builtins/unwind-ehabi-helpers.h
index ccb0765975a9..864dba716e9b 100644
--- a/contrib/compiler-rt/lib/builtins/unwind-ehabi-helpers.h
+++ b/contrib/compiler-rt/lib/builtins/unwind-ehabi-helpers.h
@@ -39,8 +39,6 @@
 #define _URC_OK       0
 #define _URC_FAILURE  9
-typedef uint32_t _Unwind_State;
 #define _US_UNWIND_FRAME_STARTING ((_Unwind_State)1)
diff --git a/lib/libgcc_s/Version.map b/lib/libgcc_s/Version.map
index 622732edb447..42a3b757d513 100644
--- a/lib/libgcc_s/Version.map
+++ b/lib/libgcc_s/Version.map
@@ -126,6 +126,12 @@ GCC_3.4.4 {
 } GCC_3.4.2;
+GCC_3.5 {
+       __aeabi_unwind_cpp_pr0;
+       __aeabi_unwind_cpp_pr1;
+       __aeabi_unwind_cpp_pr2;
 GCC_4.0.0 {
Comment 1 Dimitry Andric freebsd_committer 2019-05-21 19:29:50 UTC
Ed, I'm OK with the version map changes, but I don't see where struct _Unwind_Exception comes from normally?  The continueUnwind function just below your change also uses a _Unwind_Exception pointer, and it seems to compile just fine on other platforms... 

I see _Unwind_Exception is declared in unwind-arm.h and unwind-itanium.h, but the former is not included in case of arm, for some reason?

Similar for _Unwind_State, this is declared in unwind-arm.h, so it clearly includes that file, if there's a conflict?
Comment 2 Ed Maste freebsd_committer 2019-07-29 17:20:42 UTC
(In reply to Dimitry Andric from comment #1)

The version map changes need a slight change, we want to include them only on arm. I think I need to:

- rename libgcc_s Version.map to Symbol.map, add a Symbol.arm.map
- In Makefile set SYMBOL_MAPS=Symbol.map, and +=Symbol.arm.map on arm only
Comment 3 Ed Maste freebsd_committer 2019-11-07 15:04:21 UTC
cem changed in r354348
Comment 4 Conrad Meyer freebsd_committer 2019-11-07 15:18:15 UTC
Ah, sorry for duplicating work.  I wasn't aware of this PR.

Yeah, there were a couple problems here.  The unwind-ehabi-helpers.h file just produced conflicts with existing definitions.  There are at least two different variants of unwind.h in our tree, and different portions gcc_personality_v0 build with different headers.

Like comment 2 suggests, I added the extra GCC 3.5 symbols to ARM only using Symbol.map.  And as the description suggests, we needed those 3 other symbols as well.  No one has complained yet, afaik, but I haven't checked my email yet this morning.

I think we can drop 'arm' from the Summary and resolve this, given it's on the chopping block for 2020.
Comment 5 Conrad Meyer freebsd_committer 2019-11-07 15:18:55 UTC
(In reply to Ed Maste from comment #3)
r354347 and r354348, fwiw.  The former is the bulk of the work.
Comment 6 Ed Maste freebsd_committer 2019-11-07 15:43:50 UTC
(In reply to Conrad Meyer from comment #4)
No worries, if you check out the dependency tree for PR 233094 you can see PRs for similar issues that you may or may not have an interest in looking at:

Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-08 03:45:06 UTC
^Triage: Assign to committer that resolved (in base r354348). Assume no MFC (not referenced in commit message)
Comment 8 Ed Maste freebsd_committer 2019-11-08 16:15:17 UTC
> Assume no MFC

Indeed this would likely not be MFC'd