From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23529: Request for fixing randomize_va_space build issues Date: Fri, 09 Sep 2016 08:40:50 +0300 Message-ID: <83h99p8wbh.fsf@gnu.org> References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473399740 21019 195.159.176.226 (9 Sep 2016 05:42:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 05:42:20 +0000 (UTC) Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 09 07:42:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biEZq-0004mA-E8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 07:42:14 +0200 Original-Received: from localhost ([::1]:55970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biEZo-0001tY-A4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 01:42:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biEZi-0001tT-FB for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 01:42:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biEZe-0001JE-Aa for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 01:42:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biEZe-0001J8-72 for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 01:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1biEZe-0005f7-2s for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 01:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 05:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147339967121693 (code B ref 23529); Fri, 09 Sep 2016 05:42:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 05:41:11 +0000 Original-Received: from localhost ([127.0.0.1]:54102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biEYo-0005dp-NF for submit@debbugs.gnu.org; Fri, 09 Sep 2016 01:41:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biEYn-0005db-M0 for 23529@debbugs.gnu.org; Fri, 09 Sep 2016 01:41:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biEYf-00014I-9O for 23529@debbugs.gnu.org; Fri, 09 Sep 2016 01:41:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biEYf-000149-5n; Fri, 09 Sep 2016 01:41:01 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4299 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1biEYd-0001z7-JE; Fri, 09 Sep 2016 01:40:59 -0400 In-reply-to: <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> (message from Paul Eggert on Wed, 7 Sep 2016 13:12:27 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123100 Archived-At: > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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.