Re: The case for statically linked libc/pthread

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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