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 10:24:29 +0200 Message-ID: <83o9kpe402.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1518769419 10480 195.159.176.226 (16 Feb 2018 08:23:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 08:23:39 +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 09:23:35 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 1embIX-0001A1-Lv for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 09:23:13 +0100 Original-Received: from localhost ([::1]:50583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1embKZ-0002gY-PN for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 03:25:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1embJs-0002fc-VY for emacs-devel@gnu.org; Fri, 16 Feb 2018 03:24:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1embJo-0000yK-7u for emacs-devel@gnu.org; Fri, 16 Feb 2018 03:24:36 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1embJo-0000y2-4I; Fri, 16 Feb 2018 03:24:32 -0500 Original-Received: from [176.228.60.248] (port=1667 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1embJn-0001Bg-6P; Fri, 16 Feb 2018 03:24:31 -0500 In-reply-to: (message from Daniel Colascione on Thu, 15 Feb 2018 15:34:13 -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:222806 Archived-At: > Date: Thu, 15 Feb 2018 15:34:13 -0800 > From: Daniel Colascione > Cc: Eli Zaretskii , Angelo Graziosi , > emacs-devel@gnu.org > > I do wonder whether it makes sense to try to copy the dump into the Emacs executable itself instead of > leaving it as a separate file. We could do it independently of executable format by defining a data array in static > storage that's initially full of, say, 15MB of zeroes prefixed by a long random header (like a MIME boundary), > then, after we generate emacs.pdmp, copying the dump file into the executable at the place where we see > that random header. If the dump turns out to be bigger than that 15MB, we can fail the build and ask the user > to enlarge the array. > > I don't know of any executable format for which this scheme would fail. Wouldn't that make the dumper stuff less portable, in the sense that it would need to be compatible with low-level details of executable file formats on various systems? At least on non-ELF systems, AFAIK the flexibility of putting arbitrary sections into an executable is lower than desired. For example, before Emacs 25 the MS-Windows build would create a special section for the initialized Emacs data, which had the annoying effect of running afoul of 'strip', because Binutils don't know about this section, and therefore stripping would produce a dysfunctional executable. It also prevented re-dumping Emacs, something we had in the past and I'd like us to have again in the future. Wouldn't copying the dump into the executable hit the same problems, at least in principle? > This way, we could get rid of the current complicated dump-file location logic early in Emacs init. Can you elaborate why is that logic so complicated?