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

[stsp <stsp2@yandex.ru>]

Hi!

31.03.2023 22:12, Szabolcs Nagy пишет:
> loading from special place and loading into special place
> are different things.

Thank you for the technical comment!
Somehow that happened that this thread
went into non-technical very quickly. :(

> you gave an example of the former but then talk about the
> latter.

These are related.
File-based mmaps leave you no chance
of preserving the destination mapping,
so for my needs I took the interface for
which mmaps are not mandatory.
And then:
1. It suits my use-case surprisingly well
2. It suits as a base block for implementing
things like dlopen_with_offset(), which I
was planning to present in a subsequent
patch series. But given the fact that people
stopped believing my impl even works, I
am not so sure...

> loading from special place can be solved by writing the
> contents to a temp file and loading that.

That will end up with the casual mmaps(),
so loading to special place won't be achieved
as the result.

> loading into special place is difficult especially if you
> want to control the details of segment mapping.

Its difficult.
But my patch accumulated months of a work,
so its just here.


>   in case of
> your dlmem design it passes down a user callback that runs
> under dynamic linker locks to map segments. the interface
> contract of this callback is not documented, so it can
> deadlock

Good point.
But this is a documentation issue, right?
Not too much is needed: in the simple case
you only do anonymous mmap() in a callback.
In a more difficult case (my use-case) I do
shm_open(), ftruncate() and mmap().
Of course I need to document that any libdl
functions are disallowed, is this correct?


>   and exposes dynamic linker internals (makes
> implementation changes harder later).

Could you please clarify that part?
typedef void *
(dlmem_premap_t) (void *mappref, size_t maplength, size_t mapalign,
               void *cookie);

This only passes things needed for an initial
mmap(). The single mmap() that just defines
the mapping address.
What internals do you mean?

Also please note that the callback is optional
and is not needed for 99% of the interesting
cases possible with dlmem().

> if all you want is force mapping below 4G then you should
> have asked for an RTLD_ flag (which may not be useful
> enough or may not be supportable on all relevant targets,
> but at least does not need significant loader changes).
There is already such flag.
Unfortunately my setup is much more
complicated than that: I need to force
the mapping under 4Gb AND I need to
force it into the shared buffer which I
then mmap() to another address...
Yes, this may sound weird, and I am not
sure if you want to read my entire discussion
with Jonathon on why is that needed.
But he did a good small summary here:
https://sourceware.org/bugzilla/show_bug.cgi?id=30007#c8

Yes, its a technically difficult topic.
Yes, we spent months on only me explaining
my use-case! But why it suddenly downgraded
to flames, is a bit unclear.