[Bug 1933879] Re: libc6-lse does not replace ld.so with LSE enabled version

[Kyle Huey]

If ld.so itself can be built with -moutline-atomics, then yes, it would
fix this for us.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1933879

Title:
  libc6-lse does not replace ld.so with LSE enabled version

Status in glibc package in Ubuntu:
  New

Bug description:
  When installing libc6-lse on AArch64 (tested on focal and an AWS
  Graviton 2) the libc, pthreads, etc used by programs on the system are
  replaced with the LSE enabled versions. This is not, however, true of
  ld.so, despite an LSE enabled version of ld.so being included in
  libc6-lse. As far as I can tell this is because the other libraries
  are all substituted through some dynamic linker magic (that I don't
  understand), but ld.so's location is fixed by the PT_INTERP header
  compiled into every binary on the system, and libc6-lse doesn't e.g.
  symlink that path to the new ld.so.

  This is a problem for porting rr (https://rr-project.org/) to AArch64.
  The old-style exclusive load/store atomics are inherently non-
  deterministic and cannot be handled by rr. And not replacing ld.so
  with an LSE version means every program contains code that can execute
  the old-style atomics (in practice only programs with threads actually
  trigger that codepath in ld.so, but that's still most interesting
  programs).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1933879/+subscriptions