Re: Re: unexec development

[Camm Maguire <camm@enhanced.com>]

Greetings, and thanks for your reply!

"Jan D." <jan.h.d@swipnet.se> writes:

> > Greetings!  Just another ping on this issue.  Is anyone working on
> > unexec anymore?  Does anyone have interest in doing so?
> >
> 
> Can you describe what the benefits for Emacs would be?  Or why you
> want  this.
> 

Well, the benefits for emacs might not accrue in the immediate future.
To my very limited understanding, emacs only byte-compiles code loaded
into and executed from its heap.  GCL can compile, load, and execute
native code this way.  In principle at least, emacs might want to do
likewise at some point in the future for performance reasons.  I agree
it is far from pressing.  But the GCL compiler is written in lisp and
probably would work for emacs without too much work.

In such a setup, it makes sense that a user might want to compile and
load code into their heap which references external functions in
shared libraries which could be dlopened at runtime.  All is well
until the unexec, when the mapping from the heap to the dlopened
shared library is lost, as the start address of the latter is not
reliable..  Perhaps one might say to just relink by hand when the
saved image is restarted.  This is indeed a possibility.  But at least
in the case of gcl, this cycle of compile,load,save,restart occurs
many times in the course of building a particular application.  There
should be no reason we couldn't push the relinking work onto ld.so,
with the added advantage that the binary could be prelinked and thus
accelerated at the end.  Doing this in GCL would be to essentially
duplicate the functionality of ld.so.

As an aside, I notice that even without this, gcl images cannot be
prel at present, and I assume the same is for emacs, as the images are
formed by unexec.  This must be related to the lack of initialization
of some elf section I'd think.  Something else that could be addressed
at the same time.

Take care,


> 	Jan D.
> 
> > Camm Maguire <camm@enhanced.com> writes:
> >
> >> Greetings!  Currently, GCL and programs built on top of it
> >> (maxima,acl2,axiom), use emacs' unexec by default to save intermediary
> >> and final system images.  Compiled code is loaded and relocated
> >> dynamically at runtime, stored in an expanding .data section via sbrk,
> >> and finally dumped with unexec.
> >>
> >> I would like to extend this functionality if possible to include
> >> compiled code which references symbols in external shared libs opened
> >> again dynamically at runtime via dlopen.  Loading and relocating is
> >> straightforward, but somehow I'd need to have unexec write a
> >> new relocation record into the final image for each symbol for use by
> >> ld.so.
> >>
> >> Does this sound of interest to emacs too?  Does this trigger any ideas
> >> as to a possibly better approach?
> >>
> >> Take care,
> >> --
> >> Camm Maguire			     			camm@enhanced.com
> >> ======================================================================
> >> ====
> >> "The earth is but one country, and mankind its citizens."  --
> >> Baha'u'llah
> >>
> >>
> >> _______________________________________________
> >> Emacs-devel mailing list
> >> Emacs-devel@gnu.org
> >> http://lists.gnu.org/mailman/listinfo/emacs-devel
> >>
> >>
> >>
> >
> > -- 
> > Camm Maguire			     			camm@enhanced.com
> > =======================================================================
> > ===
> > "The earth is but one country, and mankind its citizens."  --
> > Baha'u'llah
> >
> >
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/emacs-devel
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah