* Carlos O'Donell: > I agree. TLS should be seen more like .bss/.data rather than something > that is allocated with malloc().
There wasn't consensus regarding this in 2014. See below. > If we leak memory via TLS that is a glibc bug that we can deal with, This is something that libgcc_s.so.1 does in GCC 14 if the heap trampolines are used. > but making it easier to find glibc bugs is also a benefit to the > community, but not as valuable a benefit as making TLS correctly > async-signal safe. > > Likewise we need to discuss when the memory is allocated, regardless > of which allocator is used, including allocation up-front at dlopen() > time. >> [1] https://sourceware.org/pipermail/libc-alpha/2014-January/047931.html The change conflated multiple issues: sanitizer support, async-signal-safe TLS access, and eager allocation of all TLS-related memory, so that subsequent accesses cannot fail. My impression was the main point of contention was eager allocation because it was perceived as a breaking semantic change. Nowadays, as long as we are willing to maintain both allocator variants, we could offer a choice between them controlled by a tunable. For sanitizer compatibility, we could perform eager allocation using malloc. It's probably a good idea to do it this way anyway because a separate mmap-based allocator would increase TLB pressure. Thanks, Florian _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
