dlopen related question

[Lord K.]

Hi, my function gets a dynamic library from another process BUT NOT AS A
FILENAME; my function gets the content of the dynamic library itself
(like a dynamic library file that would have been opened with fopen).
My program know the data (the content of the dynamic library file) as a
char* array.
Now I want to use the single function contained in this dynamic library.
Of course I can write the data to some .so or .dll file and then open it
again with dlopen but since I already have the whole data loaded in
memory, I wonder wether I can do it quicker.
Of course I know perfectly the name of the function (in the dynamic
library to be used) that I want to call and its prototype as well.
Of course I want some fully portable solution since the program has to be
used on Linux, Windows and Mac OS.
What is the cleanest way to do it?
Thank you by advance.

 

[Antoninus Twink]

Hi, my function gets a dynamic library from another process BUT NOT AS A
FILENAME; my function gets the content of the dynamic library itself
(like a dynamic library file that would have been opened with fopen).
My program know the data (the content of the dynamic library file) as a
char* array.
Now I want to use the single function contained in this dynamic library.
Of course I can write the data to some .so or .dll file and then open it
again with dlopen but since I already have the whole data loaded in
memory, I wonder wether I can do it quicker.

This probably happens once at program startup, so is speed really an
issue? Writing to a file would be the cleanest way to do this by far.

If you're going to use dlopen(), that requires a filename. On Linux,
one trick that might just work (untested) is to use shmem: copy the data
into shared memory, then use /proc/self/fd/n as a pathname in dlopen(),
where n is the file descriptor that was returned by shmem_open().

 

[Flash Gordon]

Hi, my function gets a dynamic library from another process BUT NOT AS A
FILENAME; my function gets the content of the dynamic library itself
(like a dynamic library file that would have been opened with fopen).
My program know the data (the content of the dynamic library file) as a
char* array.
Now I want to use the single function contained in this dynamic library.
Of course I can write the data to some .so or .dll file and then open it
again with dlopen but since I already have the whole data loaded in
memory, I wonder wether I can do it quicker.

The simple answer is you can't necessarily do it, since OSs are
generally putting in more protection against executing blocks of "data"
memory. There is definitely no C standard way.

Of course I want some fully portable solution since the program has to be
used on Linux, Windows and Mac OS.
What is the cleanest way to do it?

You will need to ask about the Unix and Windows ways of doing it. For
Linux & MacOSX a good place would be comp.unix.programmer (I don't know
where specifically to ask for earlier version of MacOS), and for Windows
a suitable Windows group (if using the SUA or Cygwin the Unix solution
might work).

 

[BGB / cr88192]

Hi, my function gets a dynamic library from another process BUT NOT AS A
FILENAME; my function gets the content of the dynamic library itself
(like a dynamic library file that would have been opened with fopen).
My program know the data (the content of the dynamic library file) as a
char* array.
Now I want to use the single function contained in this dynamic library.
Of course I can write the data to some .so or .dll file and then open it
again with dlopen but since I already have the whole data loaded in
memory, I wonder wether I can do it quicker.
Of course I know perfectly the name of the function (in the dynamic
library to be used) that I want to call and its prototype as well.
Of course I want some fully portable solution since the program has to be
used on Linux, Windows and Mac OS.
What is the cleanest way to do it?
Thank you by advance.

most simple and most generic option:
write contents to file and load in an OS-appropriate way (dlopen or
LoadLibrary).


less simple option:
write a custom dynamic linker for whatever formats one might want to deal
with (ELF, ELF64, PE/COFF, PE32+, MachO, ...).

(1) in this case, the idea would be to have some generic logic for the
dynamic linker itself, and some format-specific decoders (for example,
unpacking the specific library formats into a more generic internal format).

a simpler hybrid (loader only) scheme is also possible:
(2) the generic linker manages allocating space for "sections" and for
handling symbol resolution and relocations, and the loader pre-cooks all
this and sends it to the linker.

also possible:
(3) leaving each particular library under the control of a particular loader
(such as a PE/COFF loader, an ELF loader, ...), and using patch logic to do
more generic resolution. this allows a simpler implementation, but may
complicate things if there are more than 1 or 2 module formats.


my main dynamic linker (in my assembler/linker core) uses a mix of 1 and 3,
but would also allow 2.
1 is used for COFF and ELF object modules, dynamically-loading static libs,
....
3 is used for DLL's and SO's.

I have an x86 interpreter which presently uses a variant of 3, but it does
not, as of yet, support linking in raw COFF object modules (this is an
intended eventual feature though...). (this interpreter is not intended as a
general-purpose emulator...).