Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

Hi

I expect this to be my last (substantial) regression fix for GCC-11.

Although this is a Darwin patch, I’d welcome any comments - if none appear
then I plan to apply the patch later in the week.

tested on Darwin8 .20, x86_64-linux-gnu and powerpc-linux-gnu.

thanks
Iain

======

This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch replaces
the work-arounds.

TL;DR:
  * we provide a bumped libgcc_s.1.1 that contains the routines that were
    previously exported via symbols in libgcc_ext
  * we always use the builtins from the [new] compiler's libgcc.

This allows us to clean up a bunch of stuff and back out of the various work-
arounds.  (With 20:20 hindsight, we should have done this in the first place
but the libgcc_ext solution, described below, appeared less invasive at the
time).

====

MacOS system configurations are considered immutable by end-users - there is
no general equivalent of "apt-getting" additions to the system components,
instead updates come from Apple, at least, until an OS version is out of
support.  Additions typically come from one of the macOS OSS 'distributions'
(e.g. macports, homebrew, fink).

OSS distributions install alongside the system rather than into it - and  
policy
(for at least the major distributions) is that they do not modify the Apple-
provided one.  As far as the Darwin maintainers of GCC are concerned, this is
the only realistically supportable policy here too.

The issue here concerns the shared libgcc which not only provides the  
compiler
built-ins but also support for emulated TLS and the language-neutral parts of
the unwinder.

On macOS, there is no user-space equivalent of a completely "static"  
executable
they are all launched via the dynamic loader (dyld) and use the shared libc
(libSystem) which is only available as a dynamic library.  Nevertheless, the
static linker can use convenience libraries - so that (other than  
libSystem) an
executable can be statically-linked.

Until 10.3.9, there was no shared libgcc (or libstdc++) and all exceptions-
handling code was added from convenience libraries by the static linker.

Between 10.3.9 and 10.5.8, there is a shared libgcc_s, which provides the
unwinder and is based on gcc-4.2.1.  This is /usr/lib/libgcc_s.1.dylib.

 From 10.6 onwards the unwinder is provided (via libSystem) by libunwind  
which
is part of the LLVM project.  However, for backwards compatibility, there is
a symlink /usr/lib/libgcc_s.1.dylib => /usr/lib/libSystem.B.dylib.  Note,  
that
this link has (currently) been removed from macOS 11 systems.

We want to be able to install a new version of GCC alongside existing system
compilers, but policy dictates that we are not able to overwrite or replace
the system unwinder with the one in the new libgcc_s (it would be essentially
unworkable on any system after 10.6 anyway).

On Darwin systems /path1/to/library.dylib and /path2/to/library.dylib are
considered to be different libraries (so-called, two-level library  
namespace).

Darwin can also provide 'stub' libraries that simply re-export a sub-set of
the symbols from another library.

These two points allowed us to use two stub libraries; one containing the
symbols from the original /usr/lib/libgcc_s.1.dylib and one containing new
symbols from /path/to/compiler/install/lib/libgcc_s.1.dylib.  Since the two
libraries are distinct by the two-level namespace rules, there was no need to
alter the library build (a complete set of builtins and unwinder components  
are
still present in the /path/to/compiler/install/lib/libgcc_s.1.dylib).
The system SDKs provide the stub libraries that export the symbols present in
/usr/lib/libgcc_s.1.dylib; we added a 'libgcc_ext' stub (describing the new
symbols available with the updated GCC).

NOTE (important) that this means that code referring to
/path/to/compiler/install/lib/libgcc_s.1.dylib via libgcc_ext
will not reference any unwinder symbols in that lib [even though they were
present in the built libraries, they were not exposed via the stub].

Unfortunately the system SDKs do not provide a libgcc_s.10.X for 10.6+ and we
are not able to add our own (since SDKs are considered part of the immutable
content).  Since the systems *do* provide /usr/lib/libgcc_s.1.dylib as a link
to libSystem and /usr/lib is a necessary path for library searches, this
conflicts with any -lgcc_s.1 we add.

A series of workarounds have been used to try and resolve this, but none are
completely satisfactory; hence this patch.

--- dynamic objects

This change removes all the stubs machinery and workarounds and:

  * bumps the SO version for Darwin's libgcc_s => 1.1 avoiding the conflict.
  * the new version does not contain an unwinder, so it can be symlinked as
    libgcc_s.1 [in the compiler install path] and be backward-compatible with
    the symbols exported by libgcc_ext (per NOTE above).
  * builtins will be resolved from the new libgcc_s.  Previously, we have
    used the versions exported from /usr/lib/libgcc_s.1.dylib or libSystem
    where these are present, and from the compiler version where not.  This is
    no longer satisfactory, we need to use the versions from the compiler's
    build to pick up bug fixes (part of this regression is caused by a buggy
    conversion routine, now fixed in libgcc).  This makes sense as a general
    policy anyway - the builtins belong to the compiler, not the system (this
    same policy is already used for other system compilers).

--- static linking (noting that user-space executables are always dynamic
     but the static linker can use convenience libraries for runtimes etc.).

For macOS 10.6+ (Darwin10+), we do not provide an (automatic) ability to link
an unwinder statically - this is because there is no system-provided unwinder
convenience library - and any version we added would conflict with the  
dynamic
one in libSystem.  An end-user can always add -lgcc_eh to override that
decision (but that is not recommended).

For 10.6+ and a "-static-libgcc", we need to provide an implementation of the
emulated TLS routines - and we need to provide it in a non-conflicting  
manner.
This is resolved by linking a weak version of the routines in this case.   
Thus
such an executable can be operated together with a dynamically linked library
that refers to the version in /..../libgcc_s.1.1.dylib, because the version  
in
that is non-weak it will override the one in the exe.  If there is no  
non-weak
version then a weak version will be selected by the dynamic loaded (dyld).

For macOS versions before 10.6, we provide the same pattern as for other GCC
installs (libgcc.a libgcc_eh.a) and these have their usual content.  Of  
course,
it is the user's responsibility to avoid conflicts in that case (i.e ensure
that all or none of the libraries are statically linked; noting that  
libSystem
is fine here since it does not contain the unwinder in these OS revisions).

One final note:

We are not able to add a symlink libgcc_s.1.dylib => libgcc_s.1.1.dylib [in  
the
compiler's install lib dir] at build time, since that breaks testing (because
of the way in which DYLD_LIBRARY_PATH works, ignoring the two-level names).

This needs fixing too but is outside the scope of the current patch.

A distribution that wishes to have multiple GCC versions installed in the  
same
paths should, post-install, replace any existing older libgcc_s.1.dylib  
with a
symlink to the new libgcc_s.1.1.dylib .

gcc/ChangeLog:

	PR target/80556
	* config/darwin.c (darwin_rename_builtins): Remove workaround.
	* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Provide __eprintf via
	libgcc for macOS <= 10.4. (REAL_LIBGCC_SPEC): Adjust for the revised
	library naming.
	* config/i386/darwin.h (REAL_LIBGCC_SPEC): Remove workaround.
	* config/i386/darwin32-biarch.h (REAL_LIBGCC_SPEC): Likewise.
	* config/i386/darwin64-biarch.h (REAL_LIBGCC_SPEC): Likewise.

libgcc/ChangeLog:

	PR target/80556
	* config.host: Adjust target fragments to omit the unwinder from
	Darwin libgcc builds.  Add a weak emutls crt.
	* config/i386/t-darwin: Add X86-specific libgcc symbols.
	* config/t-darwin: Build a crat containing weak definitions for the
	emuTLS routines.
	* config/t-slibgcc-darwin: Bump SO version, remove all the handling
	for stub libraries.
	* emutls.c (EMUTLS_ATTR): New.
	(__emutls_get_address): Allow a target to add a weak
	attribute if provided.
	(__emutls_register_common): Likewise.
	* config/i386/libgcc-darwin.10.4.ver: Removed.
	* config/i386/libgcc-darwin.10.5.ver: Removed.
	* config/libgcc-libsystem.ver: Removed.
	* config/rs6000/libgcc-darwin.10.4.ver: Removed.
	* config/rs6000/libgcc-darwin.10.5.ver: Removed.
	* config/i386/libgcc-darwin.ver: New file.
	* config/t-darwin-noeh: New file.

gcc/testsuite/ChangeLog:

	PR target/80556
	* gcc.dg/torture/fp-int-convert-timode-3.c: Revert XFAIL.
	* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.

---
  gcc/config/darwin.c                           |  24 ----
  gcc/config/darwin.h                           |  65 ++++++-----
  gcc/config/i386/darwin.h                      |  27 -----
  gcc/config/i386/darwin32-biarch.h             |  26 -----
  gcc/config/i386/darwin64-biarch.h             |  26 -----
  .../gcc.dg/torture/fp-int-convert-timode-3.c  |   1 -
  .../gcc.dg/torture/fp-int-convert-timode-4.c  |   1 -
  libgcc/config.host                            |  11 +-
  libgcc/config/i386/libgcc-darwin.10.4.ver     |  98 ----------------
  libgcc/config/i386/libgcc-darwin.10.5.ver     | 102 -----------------
  libgcc/config/i386/libgcc-darwin.ver          |   2 +
  libgcc/config/i386/t-darwin                   |   2 +
  libgcc/config/libgcc-libsystem.ver            |   1 -
  libgcc/config/rs6000/libgcc-darwin.10.4.ver   |  93 ---------------
  libgcc/config/rs6000/libgcc-darwin.10.5.ver   | 106 ------------------
  libgcc/config/t-darwin                        |  12 ++
  libgcc/config/t-darwin-noeh                   |   4 +
  libgcc/config/t-slibgcc-darwin                |  94 ++++------------
  libgcc/emutls.c                               |  12 +-
  19 files changed, 92 insertions(+), 615 deletions(-)
  delete mode 100644 libgcc/config/i386/libgcc-darwin.10.4.ver
  delete mode 100644 libgcc/config/i386/libgcc-darwin.10.5.ver
  create mode 100644 libgcc/config/i386/libgcc-darwin.ver
  delete mode 100644 libgcc/config/libgcc-libsystem.ver
  delete mode 100644 libgcc/config/rs6000/libgcc-darwin.10.4.ver
  delete mode 100644 libgcc/config/rs6000/libgcc-darwin.10.5.ver
  create mode 100644 libgcc/config/t-darwin-noeh

  #ifdef __GTHREAD_MUTEX_INIT

Message ID	FC509680-1681-4DDF-BAEC-DE0D6905E585@sandoe.co.uk
State	New
Headers	show Return-Path: <gcc-patches-bounces@gcc.gnu.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=<UNKNOWN>) Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4F4Z2P20bxz9sWC for <incoming@patchwork.ozlabs.org>; Wed, 24 Mar 2021 01:46:53 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DC1E03861038; Tue, 23 Mar 2021 14:46:50 +0000 (GMT) X-Original-To: GCC-patches@gcc.gnu.org Delivered-To: GCC-patches@gcc.gnu.org Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id 3272B3861019 for <GCC-patches@gcc.gnu.org>; Tue, 23 Mar 2021 14:46:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3272B3861019 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: (qmail 90706 invoked from network); 23 Mar 2021 14:46:42 -0000 X-APM-Out-ID: 16165108029070 X-APM-Authkey: 257869/1(257869/1) 1 Received: from unknown (HELO ?192.168.1.212?) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 23 Mar 2021 14:46:42 -0000 From: Iain Sandoe <iain@sandoe.co.uk> Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Content-Transfer-Encoding: 8bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: [PATCH] Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. Message-Id: <FC509680-1681-4DDF-BAEC-DE0D6905E585@sandoe.co.uk> Date: Tue, 23 Mar 2021 14:46:40 +0000 To: GCC-patches@gcc.gnu.org X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-16.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces@gcc.gnu.org>
Series	Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. \| expand Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

Commit Message

Patch