From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DE2093858016; Mon, 23 May 2022 23:46:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE2093858016 From: "keno at juliacomputing dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/105708] New: libgcc: aarch64: init_lse_atomics can race with user-defined constructors Date: Mon, 23 May 2022 23:46:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcc X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: keno at juliacomputing dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2022 23:46:49 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105708 Bug ID: 105708 Summary: libgcc: aarch64: init_lse_atomics can race with user-defined constructors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: keno at juliacomputing dot com Target Milestone: --- Recent gcc versions provide the `-moutline-atomics` option that outlines aarch64 atomics into calls to libgcc that dispatch to either lse atomics or legacy ll/sc atomics depending on the availability of the feature on the ta= rget platform. This is useful for performance (since lse atomics have better performance characteristics), but also for projects like the rr (https://rr-project.org= /) userspace record-and-replay debugger, which emulates an aarch64 machine wit= hout ll/sc intrinsics (because ll/sc introduces non-deterministic control flow divergences that rr cannot record). The feature detection uses the following function in libgcc (config/aarch64/lse-init.c): ``` static void __attribute__((constructor)) init_have_lse_atomics (void) { unsigned long hwcap =3D __getauxval (AT_HWCAP); __aarch64_have_lse_atomics =3D (hwcap & HWCAP_ATOMICS) !=3D 0; } ``` Unfortunately, the order of this `init_have_lse_atomics` is not defined with respect to other uses of `__attribute__((constructor))`. As a result, other constructors using atomics may end up using ll/sc instructions, even if lse atomics are supported on the target (usually only a performance penalty, bu= t as mentioned above, a significant concern for projects like rr). Worse, the initialization order can change, with minor changes in the environment. E.g. recent binary builds of debian testing initialize lse too late in libpthread, breaking rr. Earlier builds had the opposite initializa= tion order allowing rr to work without issue. I can see two possibilities to introduce more determinism here: 1. Use `__attribute__((constructor(100)))` (100 being the system library priority used e.g. in libstdc++ as well) for `init_have_lse_atomics`, forci= ng a deterministic initialization order wrt user (or libc)-defined constructors. There are still ordering concerns wrt libstdc++ which also uses init_order = 100, but as far as I can tell does not use atomics in these constructors. If this changes, the priority here could be further reduced in future iterations of libgcc. 2. Switch the outlined atomics to probe lse support on first use rather than using a constructor. If this is possible, I think it would be preferable to avoid any possibility of initialization order problems, but I understand th= at there may be code size and performance concerns.=