https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #11 from James Clarke <jrtc27 at jrtc27 dot com> --- (In reply to Eric Botcazou from comment #9) > > There are similar problems for other TLS models which can be relaxed, but > > even worse than this, local dynamic uses a sethi/xor for the offset from the > > defining module's block to load a signed 32-bit value, but since it's marked > > as SI I assume a spill/reload will truncate the top 32 bits and thus lose > > any sign extension if it's negative, breaking it even with linker relaxation > > disabled. > > It turns out that this sethi/xor pair cannot generate a negative value > according to the calculation formulas of R_SPARC_TLS_LDO_HIX22 & > R_SPARC_TLS_LDO_LOX10 available at > https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html > > So, if the above formulas are [correct], relaxation is required in all cases. Yes, for Local Dynamic itself, the offset will always be positive, since it's the offset from the start of that module's TLS block. However, *all* TLS models, including Local Dynamic, can currently be relaxed to Local Exec on SPARC, which always generates negative offsets (Variant II, so static TLS blocks come just before TP). So, as far as I see it, we have two choices: 1. Disable all X -> LE relaxations in the linker. Works, but then gives suboptimal performance if some code linked into an executable is built with -fPIC rather than -fPIE (or nothing). 2. Apply this patch to GCC (assuming it still applies cleanly...). I'm struggling to understand what you meant by "relaxation is required in all cases"; did you mean *forbidden* in all cases (i.e. my point 1)?
