Messages in this thread | | | Subject | Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation | From | Szabolcs Nagy <> | Date | Thu, 20 Sep 2018 11:28:39 +0100 |
| |
On 19/09/18 22:01, Mathieu Desnoyers wrote: > ----- On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.nagy@arm.com wrote: >> note that libpthread.so is built with -ftls-model=initial-exec > > Which would indeed make these annotations redundant. I'll remove > them. > >> (and if it wasn't then you'd want to put the attribute on the >> declaration in the internal header file, not on the definition, >> so the actual tls accesses generate the right code) > > This area is one where I'm still uneasy on my comprehension of > the details, especially that it goes in a different direction than > what you are recommending. > > I've read through https://www.akkadia.org/drepper/tls.pdf Section 5 > "Linker Optimizations" to try to figure it out, and I end up being > under the impression that applying the tls_model("initial-exec") > attribute to a symbol declaration in a header file does not have > much impact on the accesses that use that variable. Reading through > that section, it seems that the variable definition is the one that > matters, and then the compiler/linker/loader are tweaking the sites > that reference the TLS variable through code rewrite based on the > most efficient mechanism that each phase knows can be used at each > stage. > > What am I missing ?
in general if you rely on linker relaxations you may not get optimal code because the linker cannot remove instructions, just nop them out.
(e.g. on aarch64 an initial-exec access is 4 instructions a general dynamic (tlsdesc) access is 6 instructions + it involves a call, so the return address has to be saved and restored (+ 3 instructions for stack operations if there were none otherwise, which the linker cannot change))
| |