The case for statically linked libc/pthread

The case for statically linked libc/pthread

[Soni L.]

It'd be nice if the kernel could keep track of which code segments
allocated memory or spawned threads, so that dlclose can release those
resources. In fact this is particularly important for correctness in
dlclose. But that requires libc to be statically linked in the first place.

There's no hope for dlclose without statically linked libc.

Re: The case for statically linked libc/pthread

[Adhemerval Zanella]

On 27/02/2022 16:57, Soni L. via Libc-help wrote:
> It'd be nice if the kernel could keep track of which code segments
> allocated memory or spawned threads, so that dlclose can release those
> resources. In fact this is particularly important for correctness in
> dlclose. But that requires libc to be statically linked in the first place.
> 
> There's no hope for dlclose without statically linked libc.

Although deprecated, glibc still supports dlopen for static binaries so it
won't help you much.  AFAIU the idea is eventually make no-op on static
build.

For dynamic linker binaries, a kernel interface would probably introduce a
large slow down on munmap (another interface to check if pointer is used
might introduce ABA issues): kernel will need to stop the process and
check N mmap against M threads (so the naive implementation will be O(n*m),
maybe with some clever data structure it could be lowered). So I think it
high unlikely that kernel will ever provide such interface, no for POSIX
like kernel like Linux.

Another option would be to make dlclose always a nop, for static and
dynamic, as musl does. However some users do expect that dlclose unmap the
memory segments and the library is reinitialized (run constructors, init
functions, etc) [1] [2].

In any case I think it is a fair assumption with current API that 
synchronization should be done by the program.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16805
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=28877