GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41242 <at> debbugs.gnu.org
Subject: bug#41242: Port feature/native-comp to Windows
Date: Sat, 23 May 2020 15:11:02 +0000

Nicolas Bértolo <nicolasbertolo <at> 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 <at> sdf.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.