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 10:50:36 +0300 Message-ID: <83d1kd8qb7.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> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473407486 5995 195.159.176.226 (9 Sep 2016 07:51:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 07:51:26 +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 09:51:22 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 1biGae-00006Q-Ic for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 09:51:12 +0200 Original-Received: from localhost ([::1]:56421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biGac-0007it-K8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 03:51:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biGaW-0007ii-DI for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 03:51:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biGaU-0003WZ-Do for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 03:51:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biGaU-0003WT-AT for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 03:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1biGaU-0000H0-3I for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 03:51: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 07:51: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.14734074581036 (code B ref 23529); Fri, 09 Sep 2016 07:51:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 07:50:58 +0000 Original-Received: from localhost ([127.0.0.1]:54158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biGaQ-0000Gd-A4 for submit@debbugs.gnu.org; Fri, 09 Sep 2016 03:50:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55731) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biGaO-0000GN-AV for 23529@debbugs.gnu.org; Fri, 09 Sep 2016 03:50:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biGaE-0003T2-J1 for 23529@debbugs.gnu.org; Fri, 09 Sep 2016 03:50:51 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biGaE-0003Sy-Fs; Fri, 09 Sep 2016 03:50:46 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4606 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1biGaD-0004dF-Ig; Fri, 09 Sep 2016 03:50:45 -0400 In-reply-to: <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> (message from Paul Eggert on Fri, 9 Sep 2016 00:10:22 -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:123102 Archived-At: > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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.