This note is related to:
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292567>
(__aeabi_unwind_cpp_pr1 has a similar status.)
It is not clear to me if other non-tier-1 architectures might have
something similar at issue, now or in the future.
Is the following expected? Appropriate?
In an armv7 context (watch for possible line wraps):
# readelf --dyn-syms /lib/libsys.so.7 | grep _cpp_
2: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
3: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr1
In more detail:
# readelf --dyn-syms /lib/libsys.so.7
Symbol table '.dynsym' contains 1211 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE WEAK DEFAULT UND __cxa_finalize
2: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
3: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr1
. . .
on aarch64:
# readelf --dyn-syms /lib/libsys.so.7 | grep _cpp_
#
on amd64:
# readelf --dyn-syms /lib/libsys.so.7 | grep _cpp_
#
For armv7 at least, it contributes to the likes of (not specific to
gcc15 for similar results):
# gcc15 -static-libgcc main.c
producing messages like:
/usr/local/bin/ld: a.out: hidden symbol `__aeabi_unwind_cpp_pr0' in
/usr/local/lib/gcc15/gcc/armv7-portbld-freebsd16.0/15.2.0/libgcc_eh.a(unwind-arm.o)
is referenced by DSO
/usr/local/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
In fact:
# gcc15 -static-libgcc -fno-exceptions main.c
also produces:
/usr/local/bin/ld: a.out: hidden symbol `__aeabi_unwind_cpp_pr0' in
/usr/local/lib/gcc15/gcc/armv7-portbld-freebsd16.0/15.2.0/libgcc_eh.a(unwind-arm.o)
is referenced by DSO
/usr/local/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
Despite the very simple C context.
In an armv7 14.3-STABLE context (so predating a
libsys.so.7 existing to be involved with libc.so.7 use):
# llvm-readelf --dyn-syms /lib/libc.so.7 | grep _cpp_
#
So in 14.* there is no such __aeabi_unwind_cpp_pr0 reference involved
when linking against libc.so.7 . (Same for __aeabi_unwind_cpp_pr1 .)
Definitely only a FreeBSD 15+ issue for what contexts can run into the
issue.
A question here is if, at least for armv7, all use of -static-libgcc for
FreeBSD 15+ needs to supply a usable/linkable pair:
__aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr1
even if -fno-exceptions is also in use.
--
===
Mark Millard
marklmi at yahoo.com
