Re: [PATCH 2/2] dlfcn,elf: implement dlmem() function [BZ #11767]

[stsp <stsp2@yandex.ru>]

14.02.2023 14:51, Florian Weimer пишет:
> * Stas Sergeev via Libc-alpha:
> With the mandatory copy, I'm not sure if this is a substantial
> improvement over the pedestrian implementation using memfd_create,
> included below.

In its current form:
- portability perhaps. Not many glibc-supported
   systems have memfd_create(), though I am not
   sure if it is any better than shm_open() here.
- one more mem copy (write() in your case)
- the need to peek into /proc just to get the
   path for dlopen(). Again, with shm_open()
   its probably simpler as it has an explicit mount
   point at least.

But considering the planned extensions, dlmem()
offers the best potential than its alternatives.
I want add a possibility for LD_AUDIT to provide
an fd to dlmem(), from which it will mmap().
Currently it does anonymous mmap(), but this
is only the first step. I want to provide it with
the fd from shm_open() to have an ability to
duplicate the solib in an address space.
I have a 32bit VM, and the memory of the
32bit process is mapped to some window
in 64bit address space. In order for this VM
to work with solib, I need to relocate the
solib to some low address in the first 4Gb.
But the aforementioned memory window
is above 4Gb. So my plan is:
- in LD_AUDIT set the load address within low 4Gb
- in LD_AUDIT provide an fd from shm_open() for dlmem()
- mmap that fd into the VM memory window
   in an upper space.

I do not suppose such an extension is possible
for any API that already has an fd. But adding
an fd arg to dlmem() itself will likely be too
confusing. So I decided to first create a minimal
impl, and then extend it via LD_AUDIT multiple
times.

OTOH how do you propose to implement dlmem()
directly on a user's buffer? If this is possible then
maybe I can try that out. But the loader will
need to move the sections around, overwriting
the existing content. Or do you want the user
to pre-load the sections to their vaddr's? In that
case he will write the half of dlmem() himself.
So my current understanding is that memcpy()
is all or nothing. If we avoid memcpy(), then we
avoid dlmem(). The dlmem() that you demonstrated,
does even more memcopies than mine.

> What's the debugger story with your dlmem variant?  It looks like GDB
> gets confused even with the memfd_create mapping, which really isn't
> great.
One can do
add-symbol-file <solib_name> <some_addr>
Unfortunately I can't figure out the right
address... lm->l_addr from dlinfo() or dli_fbase
from dladdr() do not suit, but they are close.
Some offset is probably needed and I don't
know what is it. :( Can try to figure that out
if really needed.