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?

How can I realize that, if it was never
explained? In fact, the only API review
was from Szabolcs, and he just pointed
to 2 problems that are seemingly solvable.

> Whatever happens, this whole proposal is going to be rejected, over
> and over, 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.

If no one spells out the proper reason,
then maybe.
Is it that difficult to spell out the reason
of a rejection?


>   For the sake of your time and that of the
> folks who have been pulled into this discussion, I think it would
> really, *really* be a good idea to go figure out how to solve your
> practical problem without trying to put new functionality in libc.
In fact, instead of spelling out the rejection
reason, all discussions were revolving around
solving my problem w/o modifying libc.
Basically there are currently 2 variations of
such solutions:
1. Intercept glibc's loader mmap()s on a syscall
level and bind a non-trivial logic to them (Jonathon's
proposal)
2. Implement the dynamic loader outside of glibc
(Szabolcs's proposal, and also my own wish).

I'd be happy to implement 2, but glibc doesn't
have the hooks needed for external dynamic
loader, and it doesn't even allow to use the
statically-linked patched glibc as such a loader
in a separate namespace.
Which is why so far I haven't seen a viable
proposal on solving my problem, and haven't
seen a clear explanation why the change to
glibc is going to be rejected even if the raised
concerns are all addressed.