* [musl] =?gb18030?B?ob5MaW5rZXKhv0RvZXMgTVVTTCBzdXBwb3J0IHVzaW5nIFRMUyBmb3IgYm90aCBsaWJjIGFuZCBhcHAgZGVwZW5kZW5jaWVzPw==?= @ 2024-01-21 8:56 =?gb18030?B?ODQ3NTY3MTYx?= 2024-01-21 15:46 ` [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies? Markus Wichmann 0 siblings, 1 reply; 3+ messages in thread From: =?gb18030?B?ODQ3NTY3MTYx?= @ 2024-01-21 8:56 UTC (permalink / raw) To: =?gb18030?B?bXVzbA==?= [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 772 bytes --] 1¡¢About builtin_tls Q1: What if the size of the tls used by libc is larger than the builtin size? https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L1785 Q2: I haven¡¯t seen any processing of the tls segment of ldso, so how does __copy_tls take effect at this time£¬ where was libc.tls_head be modified before this time? https://github.com/bminor/musl/blob/master/src/env/__init_tls.c#L64 Q3: Is it possible to init main thread tls by calling malloc according to the tls size of libc at this time? 2¡¢About libc and other so use tls at the same time I didn¡¯t see musl modify tls_offset when ldso uses tls, so when another so uses tls later, their tls offsets will conflict. [-- Attachment #2: Type: text/html, Size: 1027 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies? 2024-01-21 8:56 [musl] =?gb18030?B?ob5MaW5rZXKhv0RvZXMgTVVTTCBzdXBwb3J0IHVzaW5nIFRMUyBmb3IgYm90aCBsaWJjIGFuZCBhcHAgZGVwZW5kZW5jaWVzPw==?= =?gb18030?B?ODQ3NTY3MTYx?= @ 2024-01-21 15:46 ` Markus Wichmann 2024-01-21 17:13 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: Markus Wichmann @ 2024-01-21 15:46 UTC (permalink / raw) To: musl; +Cc: 847567161 Am Sun, Jan 21, 2024 at 04:56:40PM +0800 schrieb 847567161: > 1、About builtin_tls > Q1: What if the size of the tls used by libc is larger than the builtin size? > https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L1785 > What's with these HTML entities in the plain text? Your email client is misconfigured. As to the question: Libc itself cannot use TLS. It could in the static linking case (when the TLS just gets rolled into the same section as the application TLS), but not in the dynamic one. The dynlinker currently does not set up TLS in libc correctly. Not entirely familiar with the list of things that would be needed to allow libc to have TLS, but it is likely to be nontrivial. I already foresee an order-of-operations problem. See, the dynlinker on startup currently works like this: Stage 1: Process libc relative relocations Stage 2a: Process libc symbolic relocations Stage 2b: Load initial thread pointer Stage 3: Load dependencies, process all of the relocations. With TLS in libc, stage 2a would already encounter relocations referencing the TLS which gets allocated in stage 3 at the earliest, because that's when the allocator becomes available. A gordian knot. The line you've marked merely sets up a dummy thread-pointer. It will be overwritten in line 2034 if the actual initial TLS allocation is too large. That would also be the answer to your question: If the TLS is too large for builtin_tls, it gets allocated (which happens in line 2017). builtin_tls is merely an optimization to ensure small TLS sections don't need an allocation that can fail. This can also be understood as a quality improvement measure since this way, most applications cannot randomly on startup for TLS allocation reasons when the free memory runs low. Whatever good that does in an environment where the kernel gets to arbitrarily kill any process it wants to. > > Q2: I haven’t seen any processing of the tls segment of ldso, so how does __copy_tls take effect at this time, where was libc.tls_head be modified before this time? > https://github.com/bminor/musl/blob/master/src/env/__init_tls.c#L64 > See above. ldso and libc are the same in musl, and libc cannot have TLS at this time. > > Q3: Is it possible to init main thread tls by calling malloc according to the tls size of libc at this time? > Main thread TLS is allocated with malloc (well, calloc) in dynlink.c, line 2017. That is the entire TLS size, no matter how many TLS modules there are. For static linking, main thread TLS is allocated with mmap in static_init_tls(). In that case there is at most 1 TLS module. > > 2、About libc and other so use tls at the same time > I didn’t see musl modify tls_offset when ldso uses tls, so when another so uses tls later, their tls offsets will conflict. I will not repeat myself again. Ciao, Markus ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies? 2024-01-21 15:46 ` [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies? Markus Wichmann @ 2024-01-21 17:13 ` Rich Felker 0 siblings, 0 replies; 3+ messages in thread From: Rich Felker @ 2024-01-21 17:13 UTC (permalink / raw) To: Markus Wichmann; +Cc: musl, 847567161 On Sun, Jan 21, 2024 at 04:46:15PM +0100, Markus Wichmann wrote: > Am Sun, Jan 21, 2024 at 04:56:40PM +0800 schrieb 847567161: > > 1、About builtin_tls > > Q1: What if the size of the tls used by libc is larger than the builtin size? > > https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L1785 > > > > What's with these HTML entities in the plain text? Your email client is > misconfigured. > > As to the question: Libc itself cannot use TLS. It could in the static Indeed, there currently is not support for that. It's kinda an omission that should be remedied, as someday we may want to support softfloat with fenv where TLS might come into play through linking the compiler runtime (libgcc.a) that contains thread-local floating point state. But for the time being that's not something anyone seems to be interested in doing. > linking case (when the TLS just gets rolled into the same section as the > application TLS), but not in the dynamic one. The dynlinker currently > does not set up TLS in libc correctly. Not entirely familiar with the > list of things that would be needed to allow libc to have TLS, but it is > likely to be nontrivial. I already foresee an order-of-operations > problem. See, the dynlinker on startup currently works like this: > > Stage 1: Process libc relative relocations > Stage 2a: Process libc symbolic relocations > Stage 2b: Load initial thread pointer > Stage 3: Load dependencies, process all of the relocations. > > With TLS in libc, stage 2a would already encounter relocations > referencing the TLS which gets allocated in stage 3 at the earliest, > because that's when the allocator becomes available. A gordian knot. > > The line you've marked merely sets up a dummy thread-pointer. It will be > overwritten in line 2034 if the actual initial TLS allocation is too > large. > > That would also be the answer to your question: If the TLS is too large > for builtin_tls, it gets allocated (which happens in line 2017). > builtin_tls is merely an optimization to ensure small TLS sections don't > need an allocation that can fail. This can also be understood as a > quality improvement measure since this way, most applications cannot > randomly on startup for TLS allocation reasons when the free memory runs > low. Whatever good that does in an environment where the kernel gets to > arbitrarily kill any process it wants to. The intent is always to support environments where the kernel does not get to do that (overcommit disabled). What happens with the default overcommit-enabled behavior is always at best a best-effort thing. > > Q2: I haven’t seen any processing of the tls segment of ldso, so how does __copy_tls take effect at this time, where was libc.tls_head be modified before this time? > > https://github.com/bminor/musl/blob/master/src/env/__init_tls.c#L64 > > > > See above. ldso and libc are the same in musl, and libc cannot have TLS > at this time. > > > > > Q3: Is it possible to init main thread tls by calling malloc according to the tls size of libc at this time? > > > > Main thread TLS is allocated with malloc (well, calloc) in dynlink.c, > line 2017. That is the entire TLS size, no matter how many TLS modules > there are. This is not actually the public malloc but __libc_malloc. Application code (including a potentially replaced malloc) is not valid to call at this point (or any point before __libc_start_main). > For static linking, main thread TLS is allocated with mmap in > static_init_tls(). In that case there is at most 1 TLS module. > > > > > 2、About libc and other so use tls at the same time > > I didn’t see musl modify tls_offset when ldso uses tls, so when another so uses tls later, their tls offsets will conflict. If we were ever to support TLS in libc/ldso, I think it would always be accessed via the global-dynamic model, so that it doesn't have to move; its DTV slot number would just get changed. Rich ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-01-21 17:13 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-21 8:56 [musl] =?gb18030?B?ob5MaW5rZXKhv0RvZXMgTVVTTCBzdXBwb3J0IHVzaW5nIFRMUyBmb3IgYm90aCBsaWJjIGFuZCBhcHAgZGVwZW5kZW5jaWVzPw==?= =?gb18030?B?ODQ3NTY3MTYx?= 2024-01-21 15:46 ` [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies? Markus Wichmann 2024-01-21 17:13 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).