On Mon, 15 Jan 2024, Florian Weimer via Gcc wrote: > 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.
Related to eager allocation is the question of whether libgcc_s.so.1 should be loaded unconditionally by glibc at startup - doing so has much the same motivation (avoiding subsequent failures from interfaces that don't have any good way to signal failure, when glibc currently loads libgcc_s.so.1 dynamically), but also no doubt compatibility risk. -- Joseph S. Myers josmy...@redhat.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev