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 #8 from John Tobey <John.Tobey at gmail dot com> 2012-07-18 20:48:27 UTC ---
Another use case: languages like Lisp require a global, canonical, dynamic
mapping of strings to symbols.  When the language runtime implements this, it
duplicates a lot of the dynamic loader's work.  I would like to implement Lisp
symbols as ELF symbols.  This way, the system handles the common case of symbol
names known at compile time, whether in the executable or libraries.  The only
things it doesn't handle are dynamically created symbols (INTERN in Lisp).

Currently, my best option is to create the symbols as memory addresses arranged
to resemble a DSO.  I intercept calls to dlopen() and "flush" the current set
of dynamically allocated symbols.  This "flushing" operation involves writing
an ELF object with a fixed load address that lines up with the symbol values in
use, then loading the object.  I do this so the dlopen'd library will see any
symbols it may refer to.  I suspect this will require a mutex around mmap and
friends as well as DSO operations.  All this file writing and mutexing would be
unneeded if we had dlopen_phdr.

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