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

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

On 13/04/23 16:29, stsp wrote:
> Adhemerval,
> 
> 14.04.2023 00:12, Adhemerval Zanella Netto пишет:
>>> I admit you probably couldn't do that initially,
>>> because I poorly documented my API. But
>>> when Carlos asked for a more detailed spec,
>>> I did. Now you can express your objections
>>> in a detailed manner, let me even attach
>>> the prev API draft to help you doing that.
>>> Of course this draft will be simplified a lot,
>>> but for such a "generic" objections please
>>> use its current form.
>> The problem is not a poor documented ABI, the ABI itself has inherent
>> corner cases brought multiple times.
> 
> By whom?
> Where?
> You referred to some 10 years old thread,
> where I didn't even participated. Is it too
> much to ask to at least point me to a particular
> comment in that thread?

Because it is the same remark bought *multiple* times in this thread [1]
that you keep saying it is not important on the discussion:

"It would be possible to require the caller to arrange all of 
these things, but that's basically offloading A LOT of the ELF 
loading process onto the calling program and I don't think that 
makes for a reasonable public interface for glibc to provide."

And every time someone brought it [2], you just reply that this since it
does not fit in your usercase this is not an acceptable solution.  And
then we kept in circles, with multiple developers saying that this
interface-like is not reasonable, and you saying that it is the only way 
to solve your specific usercase.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=11767#c16
[2] https://sourceware.org/pipermail/libc-alpha/2023-April/146886.html

> 
> 
>>    The problem you are trying to
>> solve would be better served with a custom loader.
> 
> I wish to have a custom loader.
> But so far I don't know how to make it
> friendly to glibc. Custom loader needs
> to be able to create a link-map, and glibc
> currently doesn't have a hook to do that.
> I currently only know how to create a
> custom loader that works until glibc
> changes either struct link_map or struct
> rtld_global_ro. Such custom loader can
> be done, but it won't be very reliable.

You can just use glibc, apply your patches, and use it instead.

> 
>>> I have expressed the plans at removing all the
>>> corner cases that Szabolcs pointed to. If you
>>> point more, I'll definitely take an actions.
>>> Off-loading the biggest part to RTLD_NORELOC
>>> will reduce the proposal considerably, avoid
>>> the callback and most of other complexity, so
>>> why such a prejudice? Why can't we just discuss,
>>> amend, see what happens?
>> The RTLD_NORELOC itself is not a better approach, is just moving the
>> same corner cases that we brought to a different symbol... against
>> walking in cycles.
> 
> Why not to show these problems?
> Szabolcs always does. You always assert on
> their existence, as if I have no right to even
> ask what they are. Maybe they are obvious, maybe
> I have to realize them w/o asking, but I can't,
> I am a novice.
> Please, pretty please, can you detail those problems?
> It would be best if you detail them with the
> reference to my drafts - then I'll immediately
> understand.

Because every time someone bring the corner cases you just dismiss saying 
that either the person does not understand you [1] and it is up to review
prove you are wrong; or you dismiss saying that the remarks are not
applicable.

[3] https://sourceware.org/pipermail/libc-alpha/2023-March/146729.html
[4] https://sourceware.org/pipermail/libc-alpha/2023-March/146717.html

> 
> 
>> Do not bother, I think the best course of action is just to drop
>> the RFE.
> Why is that constructive?
> Well is not for Szabolcs, I could suspect its
> just me. But now if he points to the problems
> promptly, then I am sure its possible to do.

Because we are not moving anywhere, if you have not already get it
the replies are to try to show you the problems with the RFE proposal,
not to move toward having dlmem-like interface incorporated.