From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org
Subject: bug#23529: Request for fixing randomize_va_space build issues
Date: Fri, 09 Sep 2016 08:40:50 +0300 [thread overview]
Message-ID: <83h99p8wbh.fsf@gnu.org> (raw)
In-Reply-To: <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> (message from Paul Eggert on Wed, 7 Sep 2016 13:12:27 -0700)
> Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 7 Sep 2016 13:12:27 -0700
>
> On 09/07/2016 11:11 AM, Eli Zaretskii wrote:
> > Data that has to be dumped and loaded are accessed through pointers
>
> Sure, but the data contains pointers to other data
I guess you mean the 'previous' and 'next' pointers? Fixing that is
just a simple job of adding a fixed offset to each such pointer.
> (and perhaps to code? I haven't checked)
defsubr does that, but fixing the address of the function after
loading the dumped data is also very simple: for each defsubr, rewrite
its function pointer.
> > We'd need to plug the compiled data into
> > data structures that support the Lisp interpreter, something which the
> > compiler and linker won't help us.
>
> Ah, but they can! Because Emacs now assumes the LSB representation,
> Emacs objects now encapsulate pointers simply by adding a constant to
> them. All C compilers and linkers support that, even for addresses
> defined by other compilation units.
First, Emacs doesn't assume LSB representation when built with wide
ints. And second, I think you forget the part of the task that with
your proposed method is required to "serialize" the dumped data as C
code. AFAIU, you are talking about writing and debugging an entirely
new back-end to all the DEFSYM, DEFVAR, defsubr, etc. stuff we use
during dumping, and in addition some new code that would either
replace lisp_malloc and friends during dumping, to produce C code, or
something that would traverse the Lisp data as part of the new
implementation of unexec and convert the Lisp data into C code. That
is a formidable job in itself, which I think is much more complex than
data I/O and the necessary fixups.
next prev parent reply other threads:[~2016-09-09 5:40 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-13 12:18 bug#23529: Request for fixing randomize_va_space build issues Philippe Vaucher
2016-05-13 15:58 ` Paul Eggert
2016-05-17 16:38 ` Philippe Vaucher
2016-05-18 7:53 ` Philippe Vaucher
2016-05-18 8:21 ` Paul Eggert
2016-05-18 8:44 ` Philippe Vaucher
2016-05-20 17:52 ` Paul Eggert
2016-09-06 9:22 ` Philipp Stephani
2016-09-06 17:21 ` Paul Eggert
2016-09-06 17:40 ` Eli Zaretskii
2016-09-06 17:46 ` Philippe Vaucher
2016-09-06 17:55 ` Philipp Stephani
2016-09-06 18:04 ` Eli Zaretskii
2016-09-06 17:59 ` Eli Zaretskii
2016-09-06 18:03 ` Philipp Stephani
2016-09-06 18:32 ` Eli Zaretskii
2016-09-06 19:01 ` Philipp Stephani
2016-09-06 18:24 ` Philippe Vaucher
2016-09-06 19:11 ` Eli Zaretskii
2016-09-06 18:18 ` Clément Pit--Claudel
2016-09-06 19:09 ` Eli Zaretskii
2016-09-06 19:59 ` Clément Pit--Claudel
2016-09-06 18:44 ` Paul Eggert
2016-09-06 19:18 ` Eli Zaretskii
2016-09-06 20:37 ` Paul Eggert
2016-09-07 7:12 ` Philippe Vaucher
2016-09-07 7:40 ` Paul Eggert
2016-09-07 11:01 ` Philipp Stephani
2016-09-07 14:21 ` Eli Zaretskii
2016-09-07 16:11 ` Paul Eggert
2016-09-07 17:10 ` Eli Zaretskii
2016-09-07 17:40 ` Paul Eggert
2016-09-07 18:11 ` Eli Zaretskii
2016-09-07 20:12 ` Paul Eggert
2016-09-09 5:40 ` Eli Zaretskii [this message]
2016-09-09 7:10 ` Paul Eggert
2016-09-09 7:50 ` Eli Zaretskii
2016-09-09 8:54 ` Paul Eggert
2016-09-09 9:09 ` Eli Zaretskii
2016-09-09 16:16 ` Paul Eggert
2016-09-09 18:45 ` Eli Zaretskii
2016-09-09 19:59 ` Paul Eggert
2016-09-10 6:06 ` Eli Zaretskii
2016-09-10 7:52 ` Paul Eggert
2016-09-10 10:19 ` Eli Zaretskii
2016-09-10 23:01 ` Paul Eggert
2016-09-11 15:23 ` Eli Zaretskii
2016-09-11 16:59 ` Paul Eggert
2016-09-11 17:19 ` Eli Zaretskii
2016-09-11 19:32 ` Philippe Vaucher
2016-09-12 2:30 ` Eli Zaretskii
2016-09-12 2:58 ` Clément Pit--Claudel
2016-09-12 6:09 ` Philipp Stephani
2016-09-12 17:04 ` Eli Zaretskii
2016-09-12 14:10 ` Philippe Vaucher
2016-09-12 14:18 ` Philippe Vaucher
2016-09-13 14:47 ` Eli Zaretskii
2016-09-13 15:21 ` Philippe Vaucher
2016-09-13 15:55 ` Eli Zaretskii
2016-09-13 15:51 ` Paul Eggert
2016-09-13 19:24 ` Eli Zaretskii
2016-09-09 20:00 ` Philippe Vaucher
2016-09-10 6:13 ` Eli Zaretskii
2016-09-09 18:29 ` Andreas Schwab
2016-09-09 18:56 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2019-09-14 4:18 bug#13964: " Stefan Kangas
2019-09-14 8:52 ` Philippe Vaucher
2019-09-14 10:39 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83h99p8wbh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=23529@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=p.stephani2@gmail.com \
--cc=philippe.vaucher@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.