Re: Proposal: Slow dynamic TLS for internal glibc use

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> On 23/10/2018 09:18, Florian Weimer wrote:
>> We have a lot of legacy interfaces which are not thread-safe: strtok,
>> many, many NSS functions such as gethostbyname, wide character functions
>> when invoked with a NULL state parameter, strerror, getpass, rpmatch,
>> localtime and so on.
>> 
>> Currently, most of these functions use global variables which take up
>> space in .bss.  This introduces overhead even if they are never used,
>> and these functions are of course not thread-safe.
>
> Do we have any numbers of the overhead we are taking in consideration
> here?

Looks like there a about 34 buffers for NSS functions alone, with one
pointer, one size, and one lock each (so 2.5 words each on 64-bit
architectures), plus 1240 bytes of statically allocted structs (like
struct passd for getpwnam), plus around 40 pointers whose use isn't
quite clear to me.  So in total, that should make >2000 bytes for NSS
alone.

There's a 638 byte buffer in inet_nsap_ntoa, which was put into
libc.so.6 presumably by accident (it should have gone into libresolv).
utmp has a 384-byte buffer.  120 bytes for strsignal.

Plus lots of smaller stuff.

Thanks,
Florian