[PATCH 12/13] dlfcn,elf: implement dlmem() [BZ #11767]

[Carlos O'Donell]

On 3/29/23 10:20, stsp wrote:
> 
> 29.03.2023 19:10, Jonathon Anderson пишет:
>> Stas,
>>
>> Please do some research into the ELF file format. Neither your fdlopen implementation in the test cases nor your dlopen_with_offset implementation in the email chain implement it correctly.
>>
>> AFAICT, the first glaring issue with both of your implementations is that you have neglected the case where p_offset != p_vaddr, i.e. a segment is mmapped to a different location than its layout in the file. There are a LOT of binaries out in the wild where this is the case. Here's a quick one-liner to help you find some on your own box, I have 11712 such binaries on my Debian system:
> 
> Sure as hell p_offset != p_vaddr.
> I never ever assumed it does!
> OK, if it goes that badly, then I offer you
> a deal.

> If you present the solib with p_offset!=p_vaddr
> and demonstrate that its broken with dlmem(),
> and not because some random bug of mine but
> exactly because p_offset!=p_vaddr, then I go
> away from that dlmem() proposal forever.

The fact that such binaries can be created is enough for me to raise
a sustained objection to the inclusion of dlmem().

In glibc, and in ISO C, we deal in the slightly more abstract realm
of allowing developers to do as they wish within the boundaries of
the semantics we support. We do put some limits on what can be done
from a practical QoI perspective, but we try not be overly proscriptive.

> If you can't, then you go away.
> Do you accept that challenge?

Asking a developer to go away not the way consensus is built.

Jonathan is a scarce and precious resource, they are users that are
actively using LD_AUDIT interfaces for real work with hpctoolkit
and so are perfeclty positioned to provide us with useful feedback.

Please be kind to Jonathan.

> Sorry for offering the silly stuff, but I simply
> don't see how to proceed if we are wasting
> the time on a things like that.

If consensus can't be reached then the API will not be included
in glibc.

The real issue for me is that we are not providing a way for developers
to manage the complexity of the *setup* that is required before dlmem()
can operate reliably.

This is why I don't accept dlmem() as the right level of abstraciton.
It may solve you problem, but in glibc we need to do more than solve
singular problems, we need to provide interfaces that are useful for
many developers and the interfaces should be designed such that they
cannot be easily misused.

-- 
Cheers,
Carlos.