libc6-lse does not replace ld.so with LSE enabled version
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
glibc (Ubuntu) |
New
|
Undecided
|
Unassigned |
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:/
* Kyle Huey:
> 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).
Would outline atomics solve this rr issue?
Thanks,
Florian