Write alignment of `.tls` into `_tls_used.Characteristics`
Debate continues on whether extremely small alignment values for .tls sections can break existing code and the interpretation of `_tls_used`.
Jan Beulich expresses ongoing concern that very small alignment values for .tls sections might break existing code, despite the proposed patch. The discussion touches upon the potential issues with Microsoft’s CRT and clang/MSVC, and the reservation of the _tls_used identifier. The author of the patch has not yet provided a definitive reference to support the claims about under-alignment issues or the reserved nature of _tls_used.
- reviewer
Reiterates concern about small alignment values breaking code, questions the author's reasoning on Microsoft CRT and `_tls_used`'s special meaning, and points out cosmetic issues with line wrapping.
“My concern towards very small ->alignment_power values potentially breaking existing code remains. Your latest reply on the v1 thread didn't help there. Apart from that the patch is largely fine, except for two cosmetic issues: There are many overlong lines which want splitting. (The description also wants re-wrapping to have lines remain within 75 columns.)”
- proposer
Expresses annoyance at the repeated concerns without clear examples, questions the impact of under-alignment on EFI and mingw-w64 CRT, and defends the special meaning of `_tls_used`.
“Please show me how an under-alignment may cause an issue. Apparently this doesn't apply to EFI applications which (so far) make absolutely no use of TLS; with mingw-w64 CRT it's not possible, since tlssup.c defines pointers in .tls so alignment is guaranteed; And I don't agree that `_tls_used` might not have a special meaning. As an identifier in global scope with external linkage, it's reserved…”
- reviewer
Counters the author's arguments, stating that alignment directives matter more than pointer presence, and reiterates the lack of specification for `_tls_used`'s reserved status.
“Having pointers there guarantees nothing. It's alignment directives which matter. Please check what I've done, and please in particular point out if you see an issue with that. As before - you fail to provide a reference to where such reserved-ness is specified (for non-Windows uses in particular). I for one to not see why an EFI application could not use "_tls_used" for an entirely different pu…”
Technical Tradeoffs
- Potential performance improvements from tighter alignment vs. risk of breaking existing code.
- Enforcing stricter interpretation of ABI/file format specifications.
In Details
This discussion revolves around a patch that modifies how the alignment of Thread Local Storage (.tls) sections is written into the _tls_used.Characteristics field in PE object files. The core of the debate is Jan Beulich's concern that overly aggressive alignment optimization (reducing alignment power) could lead to performance degradation or even crashes on some platforms or with certain TLS usage patterns, and his questioning of the special significance attributed to the identifier _tls_used.
- .tls
- A section in object files that contains Thread Local Storage data. Each thread gets its own copy of this data.
- PE
- Portable Executable. The file format used for executables, DLLs, and object code in Windows systems.
- CRT
- C Runtime. A library providing essential functions for C programs, including initialization and support for TLS.
- TLS
- Thread Local Storage. A mechanism allowing variables to have thread-specific instances.