https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Mark Mentovai <mark at moxienet dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at moxienet dot com
--- Comment #10 from Mark Mentovai <mark at moxienet dot com> ---
The undefined symbols are things that libgcc_s.1 is trying to re-export from
libunwind via libSystem. None of those functions ever worked on any Apple OS.
They were present in Mac OS X 10.5 and 10.6, but broken. Since Mac OS X 10.7,
they’ve been no-ops. In macOS 15, they’ve been removed entirely. There are
other unwind functions, such as __{,de}register_frame, that remain in libunwind
and libSystem.
The no-op versions in libunwind since 10.7 (libunwind-30 is the version used in
10.7) can be seen at
https://github.com/apple-oss-distributions/libunwind/blob/libunwind-30/src/UnwindLevel1-gcc-ext.c#L220.
The modern version of that is
https://github.com/llvm/llvm-project/blob/b7a249d26fe61432050df470d23bdea417fda574/libunwind/src/UnwindLevel1-gcc-ext.c#L282.
Note that since
https://github.com/llvm/llvm-project/commit/5eb44df1b64dbd1a86b099128092a7fd2001c0ba,
these no-op functions are now only built if LIBUNWIND_ENABLE_FRAME_APIS is
enabled, and it’s off by default.
Similarly, these symbols were removed from llvm-libgcc in
https://github.com/llvm/llvm-project/commit/be91bd012123de835f64e10e677b24a7580b273c.
Because these functions were always non-working or non-functional, I’d be
surprised to find anyone in the wild referring to them on macOS, so it’s almost
certainly safe to remove them from libgcc_s.1 altogether without risking any
binary compatibility concern, as Apple themselves have done in macOS 15 and in
llvm-libgcc. This is my preferred option, as well as the simplest to implement.
If there’s any remaining concern that someone might be referencing those
symbols, it ought to be safe to implement them as either no-ops directly in
libgcc_s.1 or to implement them as code that delegates to the libunwind (via
libSystem) versions if present, and to function as a no-op otherwise. This is
the safest option, but I don’t believe that it’s necessary.
Eliminating libgcc_s.1 entirely runs the risk of breaking binary compatibility
with code built by older toolchains that may reference that library (while not
referencing the removed symbols from that library). I would tend to be more
cautious about that approach, especially if targeting a merge back to a stable
branch. But I haven’t done the research to determine how recently a toolchain
may have imposed a run-time dependency on this library.
