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

Previous Next

Full log

Message #119 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: Fri, 09 Sep 2016 10:50:36 +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: Fri, 9 Sep 2016 00:10:22 -0700
> 
> Eli Zaretskii wrote:
> 
> > I guess you mean the 'previous' and 'next' pointers?
> 
> I mean all the pointers in the data. There are more than just 'previous' and 
> 'next'. Most Lisp objects are tagged pointers, and data contains them.

Lisp objects are referenced through the obarray, which will be part of
the dumped data, so fixing that up, as part of walking through all the
structures created by temacs, will take care of this problem.  Once
again, a constant offset will do.

> > your proposed method is required to "serialize" the dumped data as C
> > code.
> 
> Sure, but that's true of any dumping method.

No.  Writing out the dumped data is almost trivial, no changes in the
current implementation are needed beyond just the file I/O itself.

> The advantage of dumping to C code is that the compiler and linker
> will deserialize it for you.

That's true, but I think you pay much more in the serialization phase.

In addition, the compiler and the linker were not meant for these
jobs, and their developers certainly don't take such jobs into
account, so we should expect to bump into unexpected problems.  By
contrast, writing the dumped data and then reading it with fixups is
something we can do ourselves without relying on any external
technologies which need to be bent to our needs.  The latter aspects
may well become a problem, not unlike what we have today, at some
future point.  As the number of people who are able to futz with Emacs
internals at this depth continues to dwindle, I don't think we want to
go through replacing this stuff more than just this once, or even
risking that.

Previous Next

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