From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14751 invoked by alias); 18 Jul 2012 20:33:04 -0000 Received: (qmail 14739 invoked by uid 22791); 18 Jul 2012 20:33:02 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_JF X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Jul 2012 20:32:51 +0000 From: "jreiser at BitWagon dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object Date: Wed, 18 Jul 2012 20:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jreiser at BitWagon dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00153.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11767 --- Comment #7 from John Reiser 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.