Re: [PATCH v9 0/13] implement dlmem() function

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

On 13/04/23 12:59, stsp wrote:
> 
>> you are adding a new interface without gathering consensus
>> that it's a good idea at all or how it should work.
> 
> I can get such a consensus only if people,
> like you do (many thanks for that!), explain
> the problems to me and suggest an amendments.
> Unfortunately, its not the case. People are
> saying that my proposal is bad, and the only
> suggested amendment is to drop it immediately. :)
> 
> But I am very thankful to those who at least did
> some side-activities for me, like discussing my
> use-case and reviewing part of the patches.
> These activities were very valuable, but the real
> problems were never discussed before, proposed
> API was not reviewed, and so on.

It is being tiring to work with your proposal because Rich already
brought the inherent issue of exposing the loader internals for ELF
objects [1] about 10 years ago, Szabolcs and myself are constantly
trying to say that is not good libc interface (regardless it solved
your specific problem), and even Jonathan tried to explore different 
alternatives.

The main problem is no one from glibc is comfortable, including myself,
to maintain and work with this interface. I don't want to maintain
another interface with a lot of corner cases.

Also the way approaching the glibc community, by not listening to 
criticism and ignoring multiple remarks; saying that you have addresses
the comments without any ack; or flooding the maillist with multiple 
version without addressing previous feedback is really, and I want to 
stress the really here, tiring.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=11767

> 
> And with your input I already advanced to the
> point where the API can be split into 2 parts,
> whereas before I thought of dlmem() as a
> thing in itself that can't be split. Now I see
> that RTLD_NORELOC can solve the biggest part
> of the puzzle alone.

Sigh, I really would like to say this is less rude manner but I will
be succinct so you and others can avoid waste time in this manner.
The "dlopen of in-memory ET_DYN or ET_EXEC object" is a *NACK* from
me, even if is split in multiple APIs.  Myself, Szabolsh, and Rich
already explained, but you seemed resolute to not accept it.

A fdlopen or even a dlopen_with_offset could make sense, FreeBSD
at least has fdlopen so it is a precedent of a realworld case.

> 
> 
>> when i said you should write your own loader i expected
>> you to create simple stubs in memory at the location
>> you want them to be and bind them to a library that
>> is loaded by libc (so you can connect your weird world
>> with the libc world).
>>
>> it looked like a simple solution to me, but i still dont
>> know exactly your requirements so in a sense we still
>> don't have a well understood use-case for any of your
>> proposed changes. so maye the use-case is where you
>> should start.
> You mean "restart". :)
> As I already explained it very thoroughly in the
> bugzilla, but you missed that and now its better
> to repeat, since the bugzilla entry had a very
> lengthy discussions afterwards.
> 
> The use-case is a VM with 32bit code inside.
> It has a 4Gb window mapped somewhere in
> a 64bit space (call it VM_window_start).
> The task is very simple: first I find the suitable
> mapping address within a VM address space.
> Such address is within the 0-4Gb boundaries.
> I relocate the solib to that "low" address.
> Unfortunately this is still not visible to the VM,
> because VM's window is at VM_window_start,
> as we remember. So in order for VM-running
> 32bit code to access the solib's data (like .bss,
> .rodata) when it gets a 32bit pointer to such
> data, I also need to map the full duplicate of
> the solib object into the address that looks like:
> 
> dupe_addr = VM_window_start + reloc_addr
> 
> For that I invented the optional dlmem flag
> that doesn't destroy the destination mapping.
> But such flag doesn't survive your requirement
> to get rid of a call-back, so in the next prop
> I'll pass a shm fd to dlmem instead, and an
> optional flag will ask dlmem() to mmap that
> fd as a destination backing-store.
> 
> So I am sure all problems can be solved!
> But of course I can't do that alone, if everyone
> just keeps saying "drop your patches immediately".