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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2012-07-18 13:59:57 UTC ---
If you want to embed the .so's in the main program binary, why are you not just
static linking them to begin with? That will give much better performance (no
time wasted on relocations, no PIC overhead, etc.) and make your program more
portable (no dependence on glibc-specific dynamic loading features or even on
POSIX dlopen).

With that said, I really question the validity of this feature request. Using
the .so in-place from data embedded in the main program would only be possible
if it's page-aligned, and would be a security risk anyway since the whole .so
image would be writable, thus requiring write+exec permission on the pages that
most security-enhanced systems don't even allow these days. Thus you'd have to
make a copy of the whole .so image, and the copy would have to be anonymous
memory that consumes actual physical runtime memory and commit charge, rather
than being a file-backed mapping. In other words, it wastes a good deal more
memory than loading a .so from a separate file.

-- 
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]