https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122413
Bug ID: 122413
Summary: [SPARC64] GCC might reorder TLS GD relocations, so
that R_SPARC_TLS_GD_ADD comes after
R_SPARC_TLS_GD_CALL
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: koachan+gccbugs at protonmail dot com
Target Milestone: ---
Created attachment 62627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62627&action=edit
C code to demonstrate the issue; compile with -O3
In GCC, it's possible for `%tgd_add`/`R_SPARC_TLS_GD_ADD` to be placed in the
delay slot of (that is, after) its corresponding
`%tgd_call`/`R_SPARC_TLS_GD_CALL` relocation (godbolt link:
https://gcc.godbolt.org/z/xqocvT5cb, example source is also attached).
A strict reading of the ELF TLS spec seems to mean that the relocations
shouldn't be reordered (see p. 20-21), but GNU ld seems to be able to cope with
this by reordering the patched instructions to be in the correct order.
However, other linkers (like mold) won't reorder the patched instructions, and
this manifests in segfaults on binaries compiled with GCC and linked with mold.
I'm reporting this to both projects, since I don't know how the resolution
would look like.
The issue report for mold can be seen at
https://github.com/rui314/mold/issues/1525.
