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

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 04/13/2023 15:01, stsp wrote:
> 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?

it does not allow handling relocation failures sensibly,
does not specify what happens with dependencies and
exposes half loaded modules to users with unclear use-case
or semantics for them.

> > 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? :)

if you fix an actual bug that's accepted.

you are adding a new interface without gathering consensus
that it's a good idea at all or how it should work.

> >   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.

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.