GNU bug report logs - #23529
Request for fixing randomize_va_space build issues

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, philippe.vaucher <at> gmail.com, 23529 <at> debbugs.gnu.org
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
Date: Wed, 07 Sep 2016 17:21:58 +0300

> Cc: p.stephani2 <at> gmail.com, philippe.vaucher <at> gmail.com, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 6 Sep 2016 13:37:20 -0700
> 
> On 09/06/2016 12:18 PM, Eli Zaretskii wrote:
> > Then users on those platforms will never be able to re-dump.
> 
> True. But they'll still be better off than they are now, since they 
> can't dump at all now. Plus, for extra credit we could dynamically link 
> the dumped object modules at Emacs startup, with the idea of making it 
> practical to re-dump.

That would be good, thanks.  I still think we should consider
approaches that don't require a compiler.

> The compiler-based approach should be simpler and more portable than 
> messing with low-level binary I/O.

You mean, 'read' and 'write'?  That's hardly problematic, and is
available on all supported platforms.  Even 'mmap' is reasonably
portable.

> Another example: on hardened platforms with PIEs
> (position-independent executables), you get a PIE for free as the
> dumped executable, instead of having to disable PIE as we do now.

I'm not sure how PIE is relevant: the stuff we dump, and need to load
into a running Emacs, is data, not code.  What am I missing?

Previous Next

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