This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 18 Jul 2012 18:15:50 +0000
- Subject: [Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object
- Auto-submitted: auto-generated
- References: <bug-11767-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=11767
--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2012-07-18 18:15:50 UTC ---
My argument was based on the usage cases presented in this bug tracker thread.
Anyway, it's wasteful and backwards for things like UPX to exist at all. They
trade startup time (valuable) and runtime memory usage (valuable) for disk
space (dirt cheap). Even if disk space is valuable, using a compressed
filesystem managed by the kernel (where demand paging will be available) is the
right solution. Putting a runtime binary decompressor in your application is
just bad design.
I maintain that any use of this feature would also be bad design. If you really
want the possibility of putting embedded so files in your binary, it makes more
sense to make toolchain feature for embedding them in the ELF binary using the
linker (where they'll be aligned and mapped with the proper permissions) rather
than supporting loading from arbitrary buffers.
--
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.