inode-based dlopen caching

[Adhemerval Zanella]

On 08/06/2021 15:17, Florian Weimer wrote:
> * Soni L.:
> 
>> The motivating use-case is hexchat plugins. Especially when they're
>> written in Rust. Rust is supposed to provide memory safety but some
>> edge-cases with dlopen break that, like truncating the shared library,
>> or closing a shared library that has spawned threads.
> 
> Truncating the shared object will always cause problems until the kernel
> implements MAP_COPY, or we stop mapping code in the dynamic loader.

Which I recall some discussion from Linus won't going to happen (unless
he changed his mind, the discussion it some years old already).

> 
> Another option (implemented by GHC and others) is to have a customer
> loader.  Except for initial-exec memory and symbol interposition, there
> is nothing magic at all about dlopen.  Applications certainly can
> implement their own object code loading mechanisms.

I think the main problem is implement all the ELF idiosyncrasies
correctly, assuming that ELF is used in first place.