From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 16 Feb 2018 17:33:36 +0200 Message-ID: <83zi49c5kf.fsf@gnu.org> References: <83o9kpe402.fsf@gnu.org> <0577d3be-cd99-60d6-d520-9e10cc7fc90e@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1518795138 16164 195.159.176.226 (16 Feb 2018 15:32:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 15:32:18 +0000 (UTC) Cc: alan@idiocy.org, angelo.g0@libero.it, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 16 16:32:13 2018 Return-path: Envelope-to: ged-emacs-devel@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 1emhzF-00024Q-3G for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 16:31:45 +0100 Original-Received: from localhost ([::1]:60890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emi1F-0006x2-CJ for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 10:33:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emi18-0006w1-6e for emacs-devel@gnu.org; Fri, 16 Feb 2018 10:33:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emi14-0003M0-8m for emacs-devel@gnu.org; Fri, 16 Feb 2018 10:33:42 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emi14-0003Ld-40; Fri, 16 Feb 2018 10:33:38 -0500 Original-Received: from [176.228.60.248] (port=2439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1emi13-0000PF-GS; Fri, 16 Feb 2018 10:33:37 -0500 In-reply-to: <0577d3be-cd99-60d6-d520-9e10cc7fc90e@dancol.org> (message from Daniel Colascione on Fri, 16 Feb 2018 07:10:42 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222817 Archived-At: > Cc: alan@idiocy.org, angelo.g0@libero.it, emacs-devel@gnu.org > From: Daniel Colascione > Date: Fri, 16 Feb 2018 07:10:42 -0800 > > The original proposal I had in mind was to make a normal data array: > > uint8_t dump[15*1024*1024] = { embedded_dump_signature }; > > And then refer to this array on code. No part of the toolchain is > allowed to remove this array. The "dump insertion" procedure we're > considering would just amount to changing the contents of this array in > an already-linked executable using dumb find-and-replace anchored on > embedded_dump_signature. I can understand how rewriting the array could work (but we'd need to know its size in advance, otherwise we'd waste memory, like Emacs on w32 does today with its dumped_data array, especially since the size during bootstrap needs to be so much larger than with byte-compiled Lisp files). But I'm not sure I understand how references to that array in the code would work. Do you mean there would be a need to "fix up" address references in the code as part of "dump insertion"? If so, that's my original suggestion from 2 years ago, which was voted down due to complexities. > I like the idea of being able to mv emacs emacs.old, make emacs, and > then have emacs.old and emacs still both run and work normally. I don't > think the numbered build mechanism you fixed completely solves the > problem, since it only works in one specific context. I imagined the fingerprint we compute is already used (or can be used) to reject dump files from a different build? If so, this could provide at least some protection form calamities.