Re: _Unwind_complete

Robert Clausecker <fuz_at_fuz.su> wrote on
Date: Mon, 25 Apr 2022 11:47:39 +0200 :

> Many ports from the ports collection fail due to an undefined
> symbol _Unwind_complete.  It appears that this symbol is an
> EABI symbol used as a part of exception unwinding, but I was
> unable to find the relevant specification with a short search.

https://github.com/ARM-software/abi-aa/releases/download/2022Q1/ehabi32.pdf

seems to be the kind of place where such is found these days.

> Neither is there a hit in /usr/src.

Capitalization mismatch?

# grep -r _Unwind_Complete /usr/main-src/ | more
/usr/main-src/contrib/libcxxrt/unwind-arm.h:void _Unwind_Complete(struct _Unwind_Exception *ucbp);
/usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:_LIBUNWIND_EXPORT void _Unwind_Complete(_Unwind_Exception* exception_object) {
/usr/main-src/contrib/llvm-project/libunwind/include/unwind.h:extern void _Unwind_Complete(_Unwind_Exception* exception_object);

The middle one is an implementation:

_LIBUNWIND_EXPORT void _Unwind_Complete(_Unwind_Exception* exception_object) {
  // This is to be called when exception handling completes to give us a chance
  // to perform any housekeeping. EHABI #7.2. But we have nothing to do here.
  (void)exception_object;
}

> Do we provide this symbol?

CA72_16Gp_ZFS armv7 main-CA7-chroot 1400053 1400053 # nm /lib/libgcc_s.so.1 | grep _Unwind
00017630 T _Unwind_Backtrace
00017630 T _Unwind_Backtrace
00017424 t _Unwind_Complete
000174f8 T _Unwind_DeleteException
000175d0 T _Unwind_FindEnclosingFunction
0001773c T _Unwind_Find_FDE
000177a8 T _Unwind_GetCFA
00017530 T _Unwind_GetDataRelBase
00017828 T _Unwind_GetGR
00017894 T _Unwind_GetIP
000177cc T _Unwind_GetIPInfo
000174a0 T _Unwind_GetLanguageSpecificData
000174cc T _Unwind_GetRegionStart
00017580 T _Unwind_GetTextRelBase
000171d4 T _Unwind_RaiseException
00017428 T _Unwind_Resume
0001752c T _Unwind_Resume_or_Rethrow
00017860 T _Unwind_SetGR
000178d0 T _Unwind_SetIP
00016c58 T _Unwind_VRS_Get
00016794 t _Unwind_VRS_Interpret
00016e28 t _Unwind_VRS_Pop
00016d40 T _Unwind_VRS_Set

FYI:

         T       A global text symbol.
. . .
         t       A local text symbol.

So:

00017424 t _Unwind_Complete

is a local symbol, not a global one.

As for lang/gcc11 (for example):

# nm /usr/local/lib/gcc11/libgcc_s.so.1 | grep _Unwind_
0001cd0c T _Unwind_Backtrace
0001c0e4 T _Unwind_Complete
0001bde8 t _Unwind_DebugHook
0001c0e8 T _Unwind_DeleteException
0001cce8 T _Unwind_ForcedUnwind
0001bf84 T _Unwind_GetCFA
0000f4e8 T _Unwind_GetDataRelBase
0000f4e8 t _Unwind_GetDataRelBase.localalias
0001c15c t _Unwind_GetGR
0001cd94 t _Unwind_GetGR.constprop.0
0001cb3c T _Unwind_GetIP
0001cb3c t _Unwind_GetIP.localalias
0001cb50 T _Unwind_GetIPInfo
0001d1d0 T _Unwind_GetLanguageSpecificData
0001d1c0 T _Unwind_GetRegionStart
0000f4f0 T _Unwind_GetTextRelBase
0001cc7c T _Unwind_RaiseException
0001cca0 T _Unwind_Resume
0001ccc4 T _Unwind_Resume_or_Rethrow
0001c1e4 t _Unwind_SetGR
0001d484 t _Unwind_SetGR
0001cb5c T _Unwind_SetIP
0001c100 T _Unwind_VRS_Get
0001c738 T _Unwind_VRS_Pop
0001c188 T _Unwind_VRS_Set
0001bdd4 t _Unwind_decode_typeinfo_ptr.constprop.0
0001cd0c t ___Unwind_Backtrace
0001cce8 t ___Unwind_ForcedUnwind
0001cc7c t ___Unwind_RaiseException
0001cca0 t ___Unwind_Resume
0001ccc4 t ___Unwind_Resume_or_Rethrow
0001c210 t __gnu_Unwind_Backtrace
         w __gnu_Unwind_Find_exidx@FBSD_1.4
0001c034 t __gnu_Unwind_ForcedUnwind
0001bf8c t __gnu_Unwind_RaiseException
0001cb9c t __gnu_Unwind_Restore_VFP
0001cbac t __gnu_Unwind_Restore_VFP_D
0001cbbc t __gnu_Unwind_Restore_VFP_D_16_to_31
0001cc54 t __gnu_Unwind_Restore_WMMXC
0001cbcc t __gnu_Unwind_Restore_WMMXD
0001c050 t __gnu_Unwind_Resume
0001c0c4 t __gnu_Unwind_Resume_or_Rethrow
0001cba4 t __gnu_Unwind_Save_VFP
0001cbb4 t __gnu_Unwind_Save_VFP_D
0001cbc4 t __gnu_Unwind_Save_VFP_D_16_to_31
0001cc68 t __gnu_Unwind_Save_WMMXC
0001cc10 t __gnu_Unwind_Save_WMMXD

So for gcc11:

0001c0e4 T _Unwind_Complete

is a global symbol. (It is not the only mismatch.)

> If not, what would be the appropriate
> place for it and who do I need to poke to have it added?

As I Remember FreeBSD has had an issue where a particular
toolchain related activity turned some global symbols into
local ones as a side effect. But I do not remember the
details.


The above was after exploring the following . . .

If there a more specific context here?

All FreeBSD platform targets? Just armv7/armv6? Just . . . ?

All toolchains? Just lang/gcc* toolchains? Just devel/llvm* ones?
Just system-clang toolchain?

Just system-clang 11? Just system clang 12?  Just system clang 13? Some
range of those but not all? All?

Just in cross builds via the likes of:

CC=/nxb-bin/usr/bin/cc
CPP=/nxb-bin/usr/bin/cpp
CXX=/nxb-bin/usr/bin/c++
NM=/nxb-bin/usr/bin/nm
LD=/nxb-bin/usr/bin/ld
. . .

but not for native builds? For both types?


Attempting possible answers . . .

Finding that www/nift seemed to be an example, it only seems
to fail for armv7(/armv6?). Building in a context with direct
armv7 code execution fails, so not cross build specific.
It used the system clang toolchain.

Freshports indicates that the last build for FreeBSD:12:armv7
was of 2.3.10 back in early 2020-Dec or so (quarterly). No
armv6 builds are shown and no other armv7 builds are shown.

Modern 2.4.11 builds show for amd64, aarch64, and i386,
going back to FreeBSD:11:*. Even FreeBSD:14:powerpc64 (latest)
and FreeBSD:13:powerpc64 (quarterly) have such. (powerpc64
does not have latest any more for FreeBSD:13:powerpc64. It
used to. Thus the old version listed for that context.)

How well this matches with what you reference, I can not
tell. But it suggest something associated with the
armv7 toolchain is involved.


===
Mark Millard
marklmi at yahoo.com