From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 16 Feb 2018 09:42:57 -0800 Message-ID: <263bde97-cc9d-03ec-1aa0-7acdcc2a68b1@dancol.org> References: <83o9kpe402.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1518802972 22566 195.159.176.226 (16 Feb 2018 17:42:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 17:42:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 Cc: emacs-devel@gnu.org To: Philipp Stephani , Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 16 18:42:48 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 1emk1c-0003wi-No for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 18:42:21 +0100 Original-Received: from localhost ([::1]:44203 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emk3d-0005OJ-6v for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 12:44:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emk2M-0005Lk-D5 for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:43:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emk2L-0006pn-Hk for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:43:06 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45270) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1emk2L-0006pL-7q for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:43:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=pHn2G6RxD7Y5PnTe+elhnB1RwCy09Ecc3WKtMexw+Jk=; b=KnRO3MU2qPPxPLhfYYP4SU4U2YUz9bv+W5mLQrgzGwJy0nZ2qPNlnZ1fywUz/vcL/oeSsM9aVUl9TeTx4FnWOfTWD1NUls/G6n/jxqqMPNhqc7uf2Wx3UEufJAntF+IMrFsEvxs5Mn4FzVE+Q9LY1t4KEXxkMvDD7E44xo8cF/iAnohw0d7DaGwjBsWN2annfn6SY8DkScbJgFKN3cyrfrJ/ZQCAxoP4ccyMFnKEQA+dlIbvPZhUUpDwC7JkEstApmWGrCePeYPo09oOSDIgIFPRNIQRn2tSZ0jmTRguByB/lb9UuYDxX7gr4TfswjPESrF/ShqDBvBmiCc9bUN5rg==; Original-Received: from [2604:4080:1321:8ab0:fc5d:9268:7f74:f879] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1emk2J-0007sw-Cj; Fri, 16 Feb 2018 09:43:03 -0800 In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:222835 Archived-At: On 02/16/2018 09:00 AM, Philipp Stephani wrote: > Andy Moreton > schrieb am Fr., 16. Feb. 2018 um > 12:31 Uhr: > > On Fri 16 Feb 2018, Eli Zaretskii wrote: > > >> 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? > > I don't understand the desire to put the dump within the eamcs > executable, as I thought the whole point of this exercise was to avoid > dodgy manipulation of executable file formats. > > > I agree. We already ship a lot of files that are expected at certain > locations, like the Emacs Lisp files or the files in `data-directory', > why should the pdump file be different? The files you've mentioned aren't as intimately tied to the Emacs binary as the pdmp file is. You can load these elc and data files into any old Emacs, but the dump has to be an _exact_ match.