public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgcc/105708] New: libgcc: aarch64: init_lse_atomics can race with user-defined constructors
@ 2022-05-23 23:46 keno at juliacomputing dot com
  2022-05-23 23:57 ` [Bug libgcc/105708] " pinskia at gcc dot gnu.org
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: keno at juliacomputing dot com @ 2022-05-23 23:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708

            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 target
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 without
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 = __getauxval (AT_HWCAP);
  __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 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, but 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 initialization
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`, forcing 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 that
there may be code size and performance concerns.

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-10-24 21:41 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-23 23:46 [Bug libgcc/105708] New: libgcc: aarch64: init_lse_atomics can race with user-defined constructors keno at juliacomputing dot com
2022-05-23 23:57 ` [Bug libgcc/105708] " pinskia at gcc dot gnu.org
2022-05-24  0:00 ` pinskia at gcc dot gnu.org
2022-05-24  0:03 ` keno at juliacomputing dot com
2022-05-24  0:08 ` pinskia at gcc dot gnu.org
2022-05-24  0:22 ` keno at juliacomputing dot com
2022-05-24  0:27 ` pinskia at gcc dot gnu.org
2022-05-24  0:47 ` keno at juliacomputing dot com
2022-05-24  0:50 ` pinskia at gcc dot gnu.org
2022-05-24  6:22 ` roc at ocallahan dot org
2022-05-24 10:00 ` wilco at gcc dot gnu.org
2022-05-24 10:21 ` jakub at gcc dot gnu.org
2022-05-24 11:15 ` wilco at gcc dot gnu.org
2022-05-24 13:56 ` wilco at gcc dot gnu.org
2022-05-25 14:54 ` cvs-commit at gcc dot gnu.org
2022-10-24 21:41 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).