Various programs depending on libunwind fail to build/run on armv6/armv7 due to the symbol __aeabi_uidiv not found. For example, various Ruby ports fail like this: -- Ruby level backtrace information ---------------------------------------- extconf.rb:700:in `<main>' extconf.rb:294:in `ensure_package_configuration' extconf.rb:287:in `have_package_configuration' extconf.rb:258:in `try_package_configuration' /usr/local/lib/ruby/3.1/mkmf.rb:988:in `checking_for' /usr/local/lib/ruby/3.1/mkmf.rb:350:in `postpone' /usr/local/lib/ruby/3.1/mkmf.rb:324:in `open' /usr/local/lib/ruby/3.1/mkmf.rb:354:in `block in postpone' /usr/local/lib/ruby/3.1/mkmf.rb:324:in `open' /usr/local/lib/ruby/3.1/mkmf.rb:354:in `block (2 levels) in postpone' /usr/local/lib/ruby/3.1/mkmf.rb:989:in `block in checking_for' extconf.rb:259:in `block in try_package_configuration' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:659:in `have_package' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:607:in `cflags_only_other' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:302:in `cflags_only_other' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:399:in `collect_cflags' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:434:in `normalize_cflags' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:434:in `loop' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:435:in `block in normalize_cflags' /usr/local/lib/ruby/gems/3.1/gems/pkg-config-1.5.1/lib/pkg-config.rb:435:in `next' -- C level backtrace information ------------------------------------------- ld-elf.so.1: /usr/local/lib/libunwind.so.8: Undefined symbol "__aeabi_uidiv" It is unclear for me what the specific problem is, where this symbol is needed and why there is a linking problem.
*** Bug 257271 has been marked as a duplicate of this bug. ***
*** Bug 259617 has been marked as a duplicate of this bug. ***
Also affects the symbols __aeabi_uldivmod, __aeabi_uidivmod and likely others. Ideally, all the __aeabi symbols should be exported as they are required by the ARM EABI and clang likes to generate references to them when it feels like it.
Just a dump of my investigation: There are two categories of __aeabi_ symbols: those that are libgcc/libcompiler_rt-like, i.e. things like integer division, and those that are libc-like, i.e. things like memcpy. Currently, lib/libc/arm/aeabi/Symbol.map defines a bunch of floating-point symbols, __aeabi_atexit, some memory-related symbols and some integer division symbols. The __aeabi_atexit and memory-related ones should be in libc as they are today. The floating-point and integer ones should not be; they belong in libgcc (which really is libcompiler_rt). Moreover, certain symbols, such as __aeabi_uidivmod, do not appear in either Symbol.map, and so are not exported from either library, rendering them inaccessible, despite being specified in "Run-time ABI for the Arm® Architecture". This needs a full audit of every symbol in the specification to determine its rightful location and to ensure it is exported. GNU/Linux systems can make a useful reference here.
The https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259617 that was made a duplicate of this one always had armv6 as a context but this one references armv7 too. Not sure of the equivalence. In fact, on armv7 (main main): # more x.c // cc -mthumb -o x x.c #include <stdio.h> #include <stdlib.h> int main() { double f; f = strtod("1.0", NULL); printf("%u\n", (unsigned int)f); } # cc -mthumb -o x x.c # uname -p armv7 so that example was either armv6 specific or for some reason 13.* and main are different. I'll remind of the proposal to possibly drop armv6 as of 14.0-release. A reference is: https://lists.freebsd.org/archives/freebsd-arm/2022-December/002091.html
(In reply to Mark Millard from comment #5) ARMv6 doesn't have FP support in thumb mode and may thus call into the __aeabi stubs when compiling for thumb. At the end of the day, it's the same issue: the __aeabi functions required by the ABI are missing, leading to problems when the linker desires to use them. The best way to fix this problem is to just add all the missing symbols.
Created attachment 246527 [details] linker script changes to export arithmetic __eabi_ symbols from libgcc_s.so
(In reply to John F. Carr from comment #7) Thank you for supplying this patch. I'll have a look. The symbol __aeabi_uldivmod is needed by a bunch of ports but is missing from your port. Is this intentional?
I did not intentionally omit __aeabi_uldivmod. I probably mistook it for a second instance of __aeabi_uidivmod. I should have used sort -u instead of manually removing duplicates. This ought to generate the right list: nm --defined-only /usr/obj/usr/src/arm.armv7/tmp/usr/lib/libgcc.a|awk '/__aeabi_[^m]/ { print $3 }' | sort -u
I've tested the changeset and found that it fixes some of the broken ports. One port, devel/omniORB, then breaks for an unrelated reason. Another one, games/toppler, fails because it expects a different symbol version: ( cd _build && gimp -i -b "(let* ((image (car(gimp-xcf-load 1 \"../datafile/font.xcf\" \"ttt\")))(layers (cadr(gimp-image-get-layers image))))(file-png-save-defaults 1 image (aref layers 0) \"font_mask_rgb.png\" \"ttt\")(gimp-quit 1))" ) GEGL-Message: 19:18:17.974: Module '/usr/local/lib/gegl-0.4/gegl-common-cxx.so' load error: /usr/local/lib/gegl-0.4/gegl-common-cxx.so: Undefined symbol "__aeabi_d2lz@GCC_3.5" This may be a bug in GEGL. Overall, I'd say add the missing entry for __aeabi_uldivmod and perhaps ship it?
I can not build gegl myself (rust is in the dependency list). I verified that the prebuilt package has the dependencies: $ objdump -T gegl-common-cxx.so|grep GC 00000000 DF *UND* 00000000 (GCC_3.5) __aeabi_unwind_cpp_pr0 00000000 DF *UND* 00000000 (GCC_3.5) __aeabi_d2lz 00000000 DF *UND* 00000000 (GCC_3.5) __aeabi_idiv 00000000 DF *UND* 00000000 (GCC_3.5) __aeabi_idivmod 00000000 DF *UND* 00000000 (GCC_3.5) __aeabi_unwind_cpp_pr1 00000000 DF *UND* 00000000 (GCC_3.5) __aeabi_l2d Possibly this is a Linuxism we want to be binary compatible with. Without evidence of that, I say don't make changes just to please gegl. Ship it with __aeabi_uldivmod added.
(In reply to John F. Carr from comment #11) I think this is because gegl is compiled with gcc on armv7. It seems like GCC_3.5 is the symbol version of this __aeabi symbol as used by gcc?
(In reply to Robert Clausecker from comment #12) [Note: I do nto recommend waiting for complete coverage of GCC_* related symbols that FreeBSD is missing.. More on this later.] None of this is a complete coverage of the symbols that GCC deepends on for aarch64. To use the exterme form as an example: GCC_4.5.0 is completely missing in FreeBSD (main): # strings /lib/libgcc_s.so.1 | grep GCC_ | more GCC_3.0 GCC_3.3 GCC_3.3.1 GCC_3.4 GCC_3.4.2 GCC_3.4.4 GCC_3.5 GCC_4.0.0 GCC_4.2.0 GCC_4.3.0 GCC_4.6.0 (That list was generated today. I'm going to use older reference material for other examples.) Quoting from an older bugzilla entry that overlapped with this issue: QUOTE # more fp-binding-failure-aarch64.cpp #include <cmath> volatile long double v=NAN; int main() { return std::isnan(v) ? 1 : 0; } # g++11 fp-binding-failure-aarch64.cpp # ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/home/root/c_tests/a.out not found The a.out has its own reference to __unordtf2@GCC_4.5.0 : # nm -a a.out | grep '@GCC_[4-9]\.' | more U __unordtf2@GCC_4.5.0 END QUOTE But even though GCC_3.0 is, by contrast, present, it is incomplete: QUOTE # more trivial.cpp // aarch64 g++12 example that shows the symbols missing for the // /usr/local/lib/gcc12/libstdc++.so.6 build involved : // // # g++12 -o trivial -L/usr/lib trivial.cpp // // This finds /usr/lib/libgcc_s.so , which in turn is a link // to /lib/libgcc_s.so.1 . int main() { } For example, in my context: # g++12 -o trivial -L/usr/lib trivial.cpp /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__floatunditf@GCC_4.2.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__subtf3@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__unordtf2@GCC_4.5.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__getf2@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__addtf3@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__letf2@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__fixunstfdi@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__multf3@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__eqtf2@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__lttf2@GCC_3.0' collect2: error: ld returned 1 exit status If it turns out that GCC/G++ happens to not generate a reference to something that is missing, such build errors do not happen when /lib/libgcc_s.so.1 is being used. But if GCC/G++ generates a reference to such, a use of a /usr/local/lib/gcc*/libgcc_s.so.1 is needed. Some ports were likely marked broken instead of being fixed. END QUOTE I recommend whatever fixes are made available be committed and then dealing with the next block when someone knowledgable and willing increases the coverage somewhat. Waiting for completeness is likely a blocking issue to progress here. Lots of examples are long known and long unchanged.
(In reply to Mark Millard from comment #13) Another old note from yet another old bugzilla: QUOTE An interesting point is amd64 vs. aarch64 for /usr/local/lib/gcc11/libgcc_s.so.1 : +GCC_4.6.0 __unordtf2 vs. +GCC_4.5.0 __unordtf2 So the GCC_* vintage is architecture specific. END QUOTE
(In reply to Mark Millard from comment #13) Thank you for these explanations. Could I interest you in moving ahead with the commit then? I assigned this one to cognet@ several weeks ago as he wanted to have a look, but it seems like he is busy with other things.
(In reply to Robert Clausecker from comment #15) I'm not a FreeBSD committer, not system, not ports. So I can not "mov[e] ahead with the commit".
Just an FYI for reference, comparing FreeBSD's /lib/libgcc_s.so.1 vs. /usr/local/lib/gcc13/libgcc_s.so.1 for GCC_* related symbol differences: # objdump -T /usr/local/lib/gcc13/libgcc_s.so.1 | sort -k6 | grep GCC_ | cut -f6-7 -w > ~/gcc13_lbgcc_s_GCC_symbols.txt # objdump -T /lib/libgcc_s.so.1 | sort -k6 | grep GCC_ | cut -f6-7 -w > ~/fbsd_main_lbgcc_s_GCC_symbols.txt # diff -u ~/fbsd_main_lbgcc_s_GCC_symbols.txt ~/gcc13_lbgcc_s_GCC_symbols.txt --- /usr/home/root/fbsd_main_lbgcc_s_GCC_symbols.txt 2023-11-28 22:18:53.230930000 -0800 +++ /usr/home/root/gcc13_lbgcc_s_GCC_symbols.txt 2023-11-28 22:18:19.358931000 -0800 @@ -1,3 +1,4 @@ +GCC_3.0 GCC_3.0 GCC_3.0 _Unwind_DeleteException GCC_3.0 _Unwind_Find_FDE GCC_3.0 _Unwind_ForcedUnwind @@ -15,50 +16,34 @@ GCC_3.0 __absvsi2 GCC_3.0 __addvdi3 GCC_3.0 __addvsi3 -GCC_3.0 __ashldi3 GCC_3.0 __ashlti3 -GCC_3.0 __ashrdi3 GCC_3.0 __ashrti3 GCC_3.0 __clear_cache -GCC_3.0 __cmpdi2 GCC_3.0 __cmpti2 GCC_3.0 __deregister_frame GCC_3.0 __deregister_frame_info GCC_3.0 __deregister_frame_info_bases -GCC_3.0 __divdi3 GCC_3.0 __divti3 +GCC_3.0 __extendsfdf2 GCC_3.0 __ffsdi2 GCC_3.0 __ffsti2 -GCC_3.0 __fixdfdi GCC_3.0 __fixdfti -GCC_3.0 __fixsfdi GCC_3.0 __fixsfti GCC_3.0 __fixunsdfdi -GCC_3.0 __fixunsdfsi GCC_3.0 __fixunsdfti GCC_3.0 __fixunssfdi -GCC_3.0 __fixunssfsi GCC_3.0 __fixunssfti GCC_3.0 __fixunsxfdi -GCC_3.0 __fixunsxfsi GCC_3.0 __fixunsxfti -GCC_3.0 __fixxfdi GCC_3.0 __fixxfti -GCC_3.0 __floatdidf -GCC_3.0 __floatdisf -GCC_3.0 __floatdixf GCC_3.0 __floattidf GCC_3.0 __floattisf GCC_3.0 __floattixf -GCC_3.0 __lshrdi3 GCC_3.0 __lshrti3 -GCC_3.0 __moddi3 GCC_3.0 __modti3 -GCC_3.0 __muldi3 GCC_3.0 __multi3 GCC_3.0 __mulvdi3 GCC_3.0 __mulvsi3 -GCC_3.0 __negdi2 GCC_3.0 __negti2 GCC_3.0 __negvdi2 GCC_3.0 __negvsi2 @@ -70,37 +55,36 @@ GCC_3.0 __register_frame_table GCC_3.0 __subvdi3 GCC_3.0 __subvsi3 -GCC_3.0 __ucmpdi2 +GCC_3.0 __truncdfsf2 GCC_3.0 __ucmpti2 -GCC_3.0 __udivdi3 -GCC_3.0 __udivmoddi4 GCC_3.0 __udivmodti4 GCC_3.0 __udivti3 -GCC_3.0 __umoddi3 GCC_3.0 __umodti3 +GCC_3.3 GCC_3.3 GCC_3.3 _Unwind_Backtrace GCC_3.3 _Unwind_FindEnclosingFunction GCC_3.3 _Unwind_GetCFA GCC_3.3 _Unwind_Resume_or_Rethrow +GCC_3.3.1 GCC_3.3.1 GCC_3.3.1 __gcc_personality_v0 +GCC_3.4 GCC_3.4 GCC_3.4 __clzdi2 -GCC_3.4 __clzsi2 GCC_3.4 __clzti2 GCC_3.4 __ctzdi2 -GCC_3.4 __ctzsi2 GCC_3.4 __ctzti2 GCC_3.4 __paritydi2 -GCC_3.4 __paritysi2 GCC_3.4 __parityti2 GCC_3.4 __popcountdi2 -GCC_3.4 __popcountsi2 GCC_3.4 __popcountti2 +GCC_3.4.2 GCC_3.4.2 GCC_3.4.2 __enable_execute_stack +GCC_3.4.4 GCC_3.4.4 GCC_3.4.4 __absvti2 GCC_3.4.4 __addvti3 GCC_3.4.4 __mulvti3 GCC_3.4.4 __negvti2 GCC_3.4.4 __subvti3 +GCC_4.0.0 GCC_4.0.0 GCC_4.0.0 __divdc3 GCC_4.0.0 __divsc3 GCC_4.0.0 __divxc3 @@ -110,12 +94,55 @@ GCC_4.0.0 __powidf2 GCC_4.0.0 __powisf2 GCC_4.0.0 __powixf2 +GCC_4.2.0 GCC_4.2.0 GCC_4.2.0 _Unwind_GetIPInfo -GCC_4.2.0 __floatundidf -GCC_4.2.0 __floatundisf -GCC_4.2.0 __floatundixf GCC_4.2.0 __floatuntidf GCC_4.2.0 __floatuntisf GCC_4.2.0 __floatuntixf +GCC_4.3.0 GCC_4.3.0 GCC_4.3.0 __bswapdi2 GCC_4.3.0 __bswapsi2 +GCC_4.3.0 __emutls_get_address +GCC_4.3.0 __emutls_register_common +GCC_4.6.0 GCC_4.6.0 +GCC_4.6.0 __addtf3 +GCC_4.6.0 __divtc3 +GCC_4.6.0 __divtf3 +GCC_4.6.0 __eqtf2 +GCC_4.6.0 __extenddftf2 +GCC_4.6.0 __extendsftf2 +GCC_4.6.0 __extendxftf2 +GCC_4.6.0 __fixtfdi +GCC_4.6.0 __fixtfsi +GCC_4.6.0 __fixtfti +GCC_4.6.0 __fixunstfdi +GCC_4.6.0 __fixunstfsi +GCC_4.6.0 __fixunstfti +GCC_4.6.0 __floatditf +GCC_4.6.0 __floatsitf +GCC_4.6.0 __floattitf +GCC_4.6.0 __floatunditf +GCC_4.6.0 __floatunsitf +GCC_4.6.0 __floatuntitf +GCC_4.6.0 __getf2 +GCC_4.6.0 __gttf2 +GCC_4.6.0 __letf2 +GCC_4.6.0 __lttf2 +GCC_4.6.0 __multc3 +GCC_4.6.0 __multf3 +GCC_4.6.0 __negtf2 +GCC_4.6.0 __netf2 +GCC_4.6.0 __powitf2 +GCC_4.6.0 __subtf3 +GCC_4.6.0 __trunctfdf2 +GCC_4.6.0 __trunctfsf2 +GCC_4.6.0 __trunctfxf2 +GCC_4.6.0 __unordtf2 +GCC_4.7.0 GCC_4.7.0 +GCC_4.7.0 __clrsbdi2 +GCC_4.7.0 __clrsbti2 +GCC_4.8.0 GCC_4.8.0 +GCC_4.8.0 __cpu_indicator_init +GCC_4.8.0 __cpu_model +GCC_7.0.0 GCC_7.0.0 +GCC_7.0.0 __divmodti4
We should follow file libgcc/config/arm/libgcc-bpapi.ver in the gcc sources and put all the __aeabi symbols in version GCC_3.5 and not in the new name EABI_1 I proposed. I assume they are all compatible.
Created attachment 247658 [details] linker script changes to export __aeabi symbols from libgcc.so
I opened a pull request, https://github.com/freebsd/freebsd-src/pull/1560.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=caab831338f4eeaa7455e981478be9fd414b7969 commit caab831338f4eeaa7455e981478be9fd414b7969 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-12-28 21:17:13 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2024-12-28 21:18:20 +0000 Export additional __aeabi_ symbols from arm's libgcc_s Some programs depend on these symbols, when they are compiled for armv6 or armv7. Closes #1560 (slightly changed due to sorting of the symbols). PR: 271087 Reported by: fuz Submitted by: jfc@mit.edu MFC after: 1 week lib/libgcc_s/arm/Symbol.map | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
*** Bug 283484 has been marked as a duplicate of this bug. ***
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f27d1ec0f5ad4d6c4833606c189c1a863967a293 commit f27d1ec0f5ad4d6c4833606c189c1a863967a293 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-12-28 21:17:13 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2025-01-04 01:01:46 +0000 Export additional __aeabi_ symbols from arm's libgcc_s Some programs depend on these symbols, when they are compiled for armv6 or armv7. Closes #1560 (slightly changed due to sorting of the symbols). PR: 271087 Reported by: fuz Submitted by: jfc@mit.edu MFC after: 1 week (cherry picked from commit caab831338f4eeaa7455e981478be9fd414b7969) lib/libgcc_s/arm/Symbol.map | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a0da8a5fc7c4b3be6aa39f4d321490ccc6b168d4 commit a0da8a5fc7c4b3be6aa39f4d321490ccc6b168d4 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-12-28 21:17:13 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2025-01-04 01:01:53 +0000 Export additional __aeabi_ symbols from arm's libgcc_s Some programs depend on these symbols, when they are compiled for armv6 or armv7. Closes #1560 (slightly changed due to sorting of the symbols). PR: 271087 Reported by: fuz Submitted by: jfc@mit.edu MFC after: 1 week (cherry picked from commit caab831338f4eeaa7455e981478be9fd414b7969) lib/libgcc_s/arm/Symbol.map | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
I think the aeabi_ functions with floating point arguments were not added correctly. By definition, they must be compiled with -mfloat-abi=softfp event if the rest of the library is compiled with hardfp abi. It is also not clear why they are added to lib/libgcc_s/arm/Symbol.map and not to lib/libc/arm/aeabi/Symbol.map, where the other (some now duplicated) aeabi_ symbols are. Also, the list of aeabi_ functions in is not complete, although the compiler_rt library contains them (__aeabi_f2d, __aeabi_f2iz...). When I looked at it, I found another problem - the whole vfp suffix dance in https://cgit.freebsd.org/src/tree/lib/libcompiler_rt/Makefile.inc#n277 is pointless, all these functions have the same extension in their name. They are expected to be compiled (again with -mfloat-abi=softfp) together with the version without the suffix , and the rt linker will select the appropriate version depending on the VFP presence. In addition, the makefile searches for resources in the wrong order, contrib/llvm-project/compiler-rt/lib/builtins is searched before contrib/llvm-project/compiler-rt/lib/builtins/<arch>, so for example a non-specific fp_mode is built, not an architecture-specific one. What now? For me the most important question is in which map (and namespace) should the aeabi_ symbols be defined (without breaking the ABI for the user space). Michal
Originally I put the float symbols in libc so we could set the rounding mode [1]. There are a few more that need to be in libc because they depend on code there, e.g. __aeabi_atexit. [1] base 01298368941f31f50e1d579d70120e953c63d34f
(In reply to commit-hook from comment #23) (In reply to commit-hook from comment #24) (In reply to Michal Meloun from comment #25) (In reply to Andrew Turner from comment #26) A question might be if the stable/14 and stable/13 commits would be appropriate to revert, updating later when main is known to be working well?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b662ca1d6cd82044c6cb79075e1830b97594bef3 commit b662ca1d6cd82044c6cb79075e1830b97594bef3 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2025-01-04 18:09:37 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2025-01-04 18:12:16 +0000 Revert "Export additional __aeabi_ symbols from arm's libgcc_s" This reverts commit caab831338f4eeaa7455e981478be9fd414b7969, because some new unresolved issues came up in bug 271087: Some programs depend on these symbols, when they are compiled for armv6 or armv7. Closes #1560 (slightly changed due to sorting of the symbols). PR: 271087 Reported by: mmel MFC after: immediately lib/libgcc_s/arm/Symbol.map | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=589cf0f3e26f8c4cb9c825be54cae246e2151484 commit 589cf0f3e26f8c4cb9c825be54cae246e2151484 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2025-01-04 18:09:37 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2025-01-04 18:13:25 +0000 Revert "Export additional __aeabi_ symbols from arm's libgcc_s" This reverts commit caab831338f4eeaa7455e981478be9fd414b7969, because some new unresolved issues came up in bug 271087: Some programs depend on these symbols, when they are compiled for armv6 or armv7. Closes #1560 (slightly changed due to sorting of the symbols). PR: 271087 Reported by: mmel MFC after: immediately (cherry picked from commit b662ca1d6cd82044c6cb79075e1830b97594bef3) lib/libgcc_s/arm/Symbol.map | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=014064b33f72c4405117eb71e6a06c8b51cc224e commit 014064b33f72c4405117eb71e6a06c8b51cc224e Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2025-01-04 18:09:37 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2025-01-04 18:13:30 +0000 Revert "Export additional __aeabi_ symbols from arm's libgcc_s" This reverts commit caab831338f4eeaa7455e981478be9fd414b7969, because some new unresolved issues came up in bug 271087: Some programs depend on these symbols, when they are compiled for armv6 or armv7. Closes #1560 (slightly changed due to sorting of the symbols). PR: 271087 Reported by: mmel MFC after: immediately (cherry picked from commit b662ca1d6cd82044c6cb79075e1830b97594bef3) lib/libgcc_s/arm/Symbol.map | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-)
We ran into another __aeabi_ issue for armv7: /usr/local/bin/ld: a.out: hidden symbol `__aeabi_unwind_cpp_pr0' in /wrkdirs/usr/ports/lang/gcc14/work/.build/./prev-gcc/libgcc_eh.a(unwind-arm.o) is referenced by DSO # find /wrkdirs/ -name config.log -exec grep -q __aeabi_unwind_cpp_pr0 {} \; -print | more /wrkdirs/usr/ports/lang/gcc14/work/.build/libdecnumber/config.log /wrkdirs/usr/ports/lang/gcc14/work/.build/libbacktrace/config.log /wrkdirs/usr/ports/lang/gcc14/work/.build/libiberty/config.log /wrkdirs/usr/ports/lang/gcc14/work/.build/lto-plugin/config.log It turns out for one of those the failure happens before the last of the link tests and the later test leads to an overall failure classification: configure:6890: checking for library containing strerror configure:6922: error: Link tests are not allowed after GCC_NO_EXECUTABLES. The official armv7 gcc14 builds have been failing for such since STANDARD_BOOTSTRAP was reenabled for gcc14.
This looks like other issue... # readelf -s /lib/libgcc_s.so.1 | grep __aeabi_unwind 23: 0000000000017eb4 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr2@@GCC_3.5 (8) 87: 0000000000017ba4 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr0@@GCC_3.5 (8) 94: 0000000000017ea8 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr1@@GCC_3.5 (8) Which is imho, consistent with: readelf -s /usr/local/lib/gcc13/libgcc_s.so.1 | grep __aeabi_unwind 81: 000000000001c324 8 FUNC GLOBAL DEFAULT 12 __aeabi_unwind_cpp_pr0@@GCC_3.5 (12) 85: 000000000001c32c 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr1@@GCC_3.5 (12) 87: 000000000001c334 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr2@@GCC_3.5 (12) 3974: 000000000001c334 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr2 3984: 000000000001c324 8 FUNC GLOBAL DEFAULT 12 __aeabi_unwind_cpp_pr0 4557: 000000000001c32c 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr1
(In reply to Michal Meloun from comment #32) For reference, from my context (aarch64 with a armv7 poudriere jail): # readelf -s /usr/obj/DESTDIRs/main-CA7-chroot-ports-local/lib/libgcc_s.so.1 | grep __aeabi_unwind 21: 000000000001674c 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr2@@GCC_3.5 (8) 85: 0000000000016570 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr0@@GCC_3.5 (8) 92: 0000000000016740 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr1@@GCC_3.5 (8) 256: 0000000000016570 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr0 273: 0000000000016740 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr1 326: 000000000001674c 12 FUNC GLOBAL DEFAULT 14 __aeabi_unwind_cpp_pr2 Note that the above does not match what you report for /lib/libgcc_s.so.1 as far as the names without @@GCC_3.5 go. It may be that the official build machines match the above. It would take someone with access to check on that. As for the partial gcc14 build's libgcc_s.so.1 files that are available: # readelf -s /usr/obj/DESTDIRs/main-CA7-chroot-ports-local/wrkdirs/usr/ports/lang/gcc14/work/.build/prev-gcc/libgcc_s.so.1 | grep __aeabi_unwind 81: 000000000001b748 8 FUNC GLOBAL DEFAULT 12 __aeabi_unwind_cpp_pr0@@GCC_3.5 (14) 85: 000000000001b750 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr1@@GCC_3.5 (14) 87: 000000000001b758 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr2@@GCC_3.5 (14) 4017: 000000000001b758 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr2 4027: 000000000001b748 8 FUNC GLOBAL DEFAULT 12 __aeabi_unwind_cpp_pr0 4603: 000000000001b750 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr1 aarch64-main-pbase aarch64 1500031 1500031 # readelf -s /usr/obj/DESTDIRs/main-CA7-chroot-ports-local/wrkdirs/usr/ports/lang/gcc14/work/.build/prev-armv7-portbld-freebsd15.0/libgcc/libgcc_s.so.1 | g rep __a 81: 000000000001b748 8 FUNC GLOBAL DEFAULT 12 __aeabi_unwind_cpp_pr0@@GCC_3.5 (14) 85: 000000000001b750 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr1@@GCC_3.5 (14) 87: 000000000001b758 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr2@@GCC_3.5 (14) 4017: 000000000001b758 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr2 4027: 000000000001b748 8 FUNC GLOBAL DEFAULT 12 __aeabi_unwind_cpp_pr0 4603: 000000000001b750 8 FUNC WEAK DEFAULT 12 __aeabi_unwind_cpp_pr1