This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object


http://sourceware.org/bugzilla/show_bug.cgi?id=11767

--- Comment #7 from John Reiser <jreiser at BitWagon dot com> 2012-07-18 20:32:34 UTC ---
(In reply to comment #5)
> My argument was based on the usage cases presented in this bug tracker thread.

"An ELF object that already is in memory" means that the bytes are in the right
place and have the correct access permissions, whether by mmap(), read(), or
store-to-memory, followed by mprotect() as appropriate.  Approximately, the
bytes will occupy an interval of pages.  Exactly, they will be an image of the
PT_LOADs, slid by some whole number of pages.  Equivalently, they will be what
is described by struct dl_phdr_info during a callback from dl_iterate_phdr(). 
The pages need to be "blessed" as an in-memory module that the dynamic linker
recognizes, and connected to the rest of the collection of modules in memory. 
No "mass copying" or re-arranging is necessary.

In the proposed dlopen_phdr(), one of the ElfXX_Phdr will be a PT_PHDR, and the
slide value for the module is equal to the difference between the actual
address and the PT_PHDR.p_vaddr.  (If there is no such PT_PHDR, then use zero.)
Knowing that, then rtld can find the PT_DYNAMIC, and process it.  Create the
internal structures which keep track of a loaded module, apply the DT_SONAME,
load the DT_NEEDED dependencies, connect the DT_SYMTAB, DT_STRTAB, and
DT_{GNU_}HASH, perform the indicated relocations, call the DT_INIT_ARRAY
functions, etc.

Regarding the use case(s): Storage that is "dirt cheap" tends to be "dirt
slow."  A class 4 SDHC flash memory device supplies less than 4 MB/s, whereas
RAM usually gives at least 100 MB/s.  Most hand-held mobile devices do not
offer a compressed filesystem.  Managing files (including updates) using
something like jffs2 requires complex code, battery energy, and perhaps a
somewhat sophisticated user to understand the behavior of fragmentation.  "Dirt
cheap" does not mean a cost of zero, and every $0.10 matters.  A device with
8MB RAM and 8GB flash storage cannot afford to use 6MB to store a program with
library, if 3.5MB would be enough because of compression.  "Decompress to
filesystem, then dlopen" costs time (and an unneeded write to flash stoage.) 
Distributing 3.5MB "over the air" is understandable: it's a "song" (same size
as typical MP3 audio).  Distributing 6MB gets noticed.  I would like to live in
a world where such costs did not matter (or were absorbed by somebody else),
but today I am forced to pay, and probably will be for at least a couple more
years.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]