From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 16 Feb 2018 17:00:52 +0000 Message-ID: References: <83o9kpe402.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f4f5e805a9ec1cac480565574a45" X-Trace: blaine.gmane.org 1518800845 22205 195.159.176.226 (16 Feb 2018 17:07:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 17:07:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 16 18:07:21 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 1emjTa-0004LI-4a for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 18:07:10 +0100 Original-Received: from localhost ([::1]:41002 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emjVV-000683-FY for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 12:09:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emjNi-0007pr-SH for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:01:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emjNh-0008De-Hb for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:01:06 -0500 Original-Received: from mail-lf0-x229.google.com ([2a00:1450:4010:c07::229]:44102) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1emjNh-0008DD-5E for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:01:05 -0500 Original-Received: by mail-lf0-x229.google.com with SMTP id v9so2911802lfa.11 for ; Fri, 16 Feb 2018 09:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jWaBuE1s7LxxEGjDSvWIk8oVJrpRfDBl87NJZa7lfMk=; b=YoiyfNJRX4h0TCO+DAEUp4X2W+riG8Yx+UYDLCGBIvAZsLHcR8GnEFC/cXV0cQSUKW AYm9M6Hkzv3uqyE5IBas9SgUrIilvHaAbw2Wkfzg4ovf7mQqmHMh8zhlHtVt+1d05pKv CQuvJi7hBisMSxDiDsPgkptcCzfj+HTkHUbOQp0jfIR1AjQdWUj+XaYiYCjdTiqFktvT bNb7wzKiDlfXIY0iFvjB/2VRQi1UCm2r/M/XiB7nwf3inRMp2T1qB9IYFPFxpqTtIGtN MmjUffXk00vL45S+GqrPSqEMxw74gI01v0GXQcFZl5VE13ma+v1f2FsYn5XT7jYTgUdJ SjFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jWaBuE1s7LxxEGjDSvWIk8oVJrpRfDBl87NJZa7lfMk=; b=e3hlOf6Lw1M+fUpPBtLxl51zMKPlPm7KxmY6+PjZdhoYPLNdNcE0Ix3YgXygE0NjZ1 S/aRUGPX/XTK+8CNbiCF3WlEqT8PmehvUjQSc5O1+h4WxRU8Xf9txdGZZ2sNQbQCNbFv reSRmRFItV2+KkPZv9rc3H/TEkRLtdsu96q9PpTJL7Gblq6j/+j6IGgU1M/8kxSnVhpb 5ljb41Gb3LhS7Sx8PhYgqmnxUGu+rzZyaX4/QsCe7Yo86h3RY4XpAMiITDcr4dDtz7hF zzGQ7cRqkSEPHZQ6MWyVgX9FJLL3lxkRdIyPfpskUOaRn9nlTsaNTVwq9YXKx6qQqcfd TqaQ== X-Gm-Message-State: APf1xPB/xvYDg1/L0EMjaxVBj8ArC4BRXM5sbm/yKTyrVof/8kl/opgt b00BLxhPYSWVxsHMrlKV2NSiSNzERYypcvz0ILY= X-Google-Smtp-Source: AH8x225VPOgjrpKEk7/reXn1jOOt4tODZELGCX1m2XyRu/OcBgmRScSBZo+sPzSHsw8+F2KnH/KEJfR7IpQT923QjEg= X-Received: by 10.46.12.65 with SMTP id o1mr4705091ljd.68.1518800463504; Fri, 16 Feb 2018 09:01:03 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::229 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:222831 Archived-At: --f4f5e805a9ec1cac480565574a45 Content-Type: text/plain; charset="UTF-8" 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? --f4f5e805a9ec1cac480565574a45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Andy M= oreton <andrewjmoreton@gmail= .com> schrieb am Fr., 16. Feb. 2018 um 12:31=C2=A0Uhr:
On Fri 16 Feb 2018, Eli Zaretskii wrote:

>> Date: Thu, 15 Feb 2018 15:34:13 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Angelo Graziosi <angelo.g0@libero.it>,
>>=C2=A0 ema= cs-devel@gnu.org
>>
>> I do wonder whether it makes sense to try to copy the dump into th= e Emacs executable itself instead of
>> leaving it as a separate file. We could do it independently of exe= cutable 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 1= 5MB, 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 wo= uld fail.
>
> Wouldn't that make the dumper stuff less portable, in the sense th= at
> 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.=C2=A0 For=
> example, before Emacs 25 the MS-Windows build would create a special > section for the initialized Emacs data, which had the annoying effect<= br> > of running afoul of 'strip', because Binutils don't know a= bout this
> section, and therefore stripping would produce a dysfunctional
> executable.=C2=A0 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 problem= s,
> 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 th= at are expected at certain locations, like the Emacs Lisp files or the file= s in `data-directory', why should the pdump file be different?=C2=A0
--f4f5e805a9ec1cac480565574a45--