bug#41242: Port feature/native-comp to Windows

[Andrea Corallo]

Nicolas Bértolo <nicolasbertolo@gmail.com> writes:

>> This is something we have to define.  Currently we only complain if
> one
>> of the defined functions that was dumped cannot be found in the new
>> .eln.  My preference would be to sign each .eln used for dump to
> make
>> sure what we are loading is what we dumped and refuse to load
> otherwise.
>
> What if we find out where the linker has put the shared library, copy
> that region
> of memory into the dump file and when loading Emacs we mmap that data
> into
> same address it was?
> It is essentially saving the result of the linker for later use. This
> would require
> no ASLR and doing it ASAP to prevent the something from using that
> address space.

I don't think would fly: You are not garanteed to be able to obtain the
same mmaped address anyway and we cannot go for a solution that does not
support ASLR.  In general to be portable it cannot rely on assumptions
or low level tricks.  I think these are (at least part of) the reasons
why we moved away from unexec.

> Another option: statically link the .eln files (we'd need libgccjit
> to create static libraries)
> into the final Emacs executable. This would take care of function
> definitions and
> loading the dump would take care of the rest.

Is not that simple, loading eln is mutating the environment with side
effects, function definition is just a part of that.

Even more important we must support subsequent dumps.

  Andrea

-- 
akrl@sdf.org