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

[stsp <stsp2@yandex.ru>]

12.04.2023 23:20, Rich Felker пишет:
> On Wed, Apr 12, 2023 at 11:00:19PM +0500, stsp wrote:
>> 12.04.2023 22:23, stsp пишет:
>>> The same "lazy relocation" can even be
>>> applied to a regular dlopen().
>> Of course it can't, as dlopen() is expected
>> to call library ctors. So only with an optional
>> dlmem() flag such behavior should be performed,
>> in which case dlsetbase() should also do the
>> final relocation and ctors calling.
> Have you not realized yet how far outside any concept of "reasonable"
> this ever-expanding contract is?

OK, consider this small proposal (not dlmem):

RTLD_NORELOC - new flag to skip the relocation step.

dlrelocate(handle, base) - new call to explicitly
perform the relocation (and call ctors) that was
skipped with RTLD_NORELOC flag.

That alone already solves most of what I wanted
to achieve with dlmem(). Namely, it allows the
user to specify the relocation address he needs.
He does so by manually moving the solib image
to the desired location, and then calling dlrelocate()
with new base address.

Could you please tell me beforehand why that
proposal will be rejected?


> Whatever happens, this whole proposal is going to be rejected, over
> and over,

I believe you, but the question is still "why".
In all the other projects I contributed in, the
proposals were in most cases getting the
change requests. And in glibc, the only available
change request is to drop the proposal? :)


>   and the more effort you pour into engineering it on the
> belief that it will somehow eventually be accepted, the more
> disappointed (and maybe angry?) you're going to be at the people who
> have to keep rejecting it.
This is a wrong assumption, because in a
worst case this code will make it into a standalone
loader. So far I know how to do that only until
glibc changes one of its core structs, like rtld_global_ro
or link_map. With every such change, the loader
will stop working. So that would be a very unfortunate
and unreliable solution. I'd like to avoid it, but
there is no risk that my efforts working on that
code will be wasted.