Loading .so Files From Memory [duplicate]

Question

Possible Duplicate:
dlopen from memory?

I've seen this for Windows' DLL files, being loaded from a memory buffer, but I cant find it anywhere for Linux, and "ld" source code is the most complex code I've ever seen. So:

Is there any example of loading .so files from memory? Even a simple one that I can finish? I just don't know where to start, even though I've read most of the ELF specifications it's still mysterious to me.

Napiform

the .so is sent over a socket connection, and im looking for a solution mate, not an alternative. – Napiform

@Napiform you're looking for a solution to a problem that you've defined quite narrowly. You currently lack the knowledge to code a .so from memory, and want to pay someone else to do it. The alternatives make more sense, unless you can give us some context. – Mice

the .so is being sent over sockets, i don't wanna write it to disk since my app may not have the privilege to write files to disk, so i wanna run it from memory to avoid any of those on any platform and not just linux. – Napiform

killercode... Could you find your answer? Do you have some code to show? – Xerosis

Answer 1

You're looking at the source code of a wrong thing: ld doesn't do program and library loading. Instead, you should look at the source code of dlopen and dlsym functions found in libc. Also, you should look at the source of the dynamic linker: ld-linux.so (the true name varies with the platform; execute ldd /bin/ls to find out where the dynamic linker resides).

ELF parsing isn't difficult, but it requires attention to detail and understanding of assembly code for the particular CPU; you need also ABI specification for your platform (and it's different for 32- and 64-bit linux, and is also different between CPUs.)

If you just need to load object files from memory at run-time (i.e., it doesn't have to be a SO), you can look at X11 project: they have implemented a module system which, basically, loads object code at some address and relocates it.

Jeans

Answer 2

You need dlopen() family of functions (on GNU/Linux, they are defined in /usr/include/dlfcn.h).

For an example, take a look at how PHP does modules.

Artful

i know how to use .so from disk, i wanna use them from memory, they wont exists on disk – Napiform

Answer 3

What does "loading .so files from memory" means to you?

If you have any *.so file, then it is in some file system, and has a path. Then just use dlopen on it.

If it is not a file, what is it? How did you get in memory? What exactly have you in memory? (Do you have an ELF header and ELF layout in memory?)

If you have enough information to make an ELF *.so file, dump (i.e. write) such file into some file system (use a temporary filesystem like tmpfs if you are concerned with disk performance). Then dlopen that.

If you don't have enough information to make an ELF .so file, then probably you are dynamically building code in memory. Look at what existing machine code generating infrastructure (like LLVM, GCCJIT, libjit, GNU lightning, LuaJit ....) are doing.

If you have a full functional code in memory, ensure that the memory is executable with mmap & mprotect and jump into it (e.g. using function pointer tricks).

Coughlin

I'm quite surprised by the negative feedback. What did I say wrong? Why is my answer not relevant? – Coughlin

Not exactly answering what he seems to be trying to (stubbornly) achieve the way he wants to, but this information is generally useful. +1 – Mice

I don't understand what exactly the original poster means by "loading a .so file from memory"... (or even loading any kind of file from memory), since a file can only be read from a file system. I would guess that Windows had such a function because (IIRC) on windows several processes cannot operate on a file at once (for example, you cannot remove a file which is opened by another process on Windows, but you can do that on Linux). – Coughlin

He envisions passing a .so file over a socket, so he has the contents of an entire file in memory, and wants to in effect dlopen() it from there, instead of from on-disk. – Mice

The original poster did not mention any kind of socket or pipe. But if he is getting the content of a .so ELF file on such a (non-seekable, non-mmap-able) file descriptor, the only sensible option is to write it on a file, then dlopen that file. – Coughlin