https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Looking at that patchset, I just want to say that the use of TLS in libgcc is very much undesirable, it affects every program even when not using exceptions (significant portion of them), especially when it uses that much (6 * sizeof(void *) * 8 + sizeof(void *) + 2 * 8 = 408 bytes per thread is significant, plus it uses the slow local dynamic TLS model. Similarly, the 64 recursive locks in libc, again, significant amount of memory per process that doesn't care about exceptions, and especially signficiant slowdown on dlopen/dlclose. While some programs abuse exceptions for normal control flow, others abuse dlopen/dlclose. A rwlock ought to be better, but I don't think we have recursive rwlock in libc yet (all we need is being able to recursively lock it for writing, for reading we might not need to allow recursion in this case). Plus the current rwlock implementation still takes uses a per-process lock to guard the inner operations on the rwlock, so while rwlock helps with longer critical sections, for very short ones it likely doesn't scale all that well.
