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

Previous Next

Package: emacs;

Reported by: Nicolas Bértolo <nicolasbertolo <at> gmail.com>

Date: Wed, 13 May 2020 19:28:01 UTC

Severity: wishlist

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


Message #260 received at 41242 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41242 <at> debbugs.gnu.org
Subject: Re: bug#41242: Port feature/native-comp to Windows
Date: Sat, 23 May 2020 11:41:19 -0300
[Message part 1 (text/plain, inline)]
> 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.

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.

Nicolas
[Message part 2 (text/html, inline)]

This bug report was last modified 5 years and 42 days ago.

Previous Next


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