From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: dancol@dancol.org Newsgroups: gmane.emacs.devel Subject: Re: pdumping "into" the executable Date: Mon, 26 Feb 2018 15:34:41 -0800 Message-ID: References: <87d10rpid8.fsf@tromey.com> <40f9317e9ee2220ba612cc117d6174c2.squirrel@dancol.org> <05c667d7-ad68-925b-75e6-5834ee528aa6@dancol.org> <41ac3ca1-a850-2c8a-0ad4-6b410b3932aa@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1519688004 6161 195.159.176.226 (26 Feb 2018 23:33:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Feb 2018 23:33:24 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , Tom Tromey , Stefan Monnier , emacs-devel@gnu.org To: "Paul Eggert" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 27 00:33:20 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 1eqSGl-0000w8-C5 for ged-emacs-devel@m.gmane.org; Tue, 27 Feb 2018 00:33:19 +0100 Original-Received: from localhost ([::1]:33856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqSIm-0002Pu-D7 for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 18:35:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqSIA-0002PV-C5 for emacs-devel@gnu.org; Mon, 26 Feb 2018 18:34:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqSI9-0007wa-Cs for emacs-devel@gnu.org; Mon, 26 Feb 2018 18:34:46 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:37278) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eqSI9-0007vh-3R for emacs-devel@gnu.org; Mon, 26 Feb 2018 18:34:45 -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:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=7OhnV7lXH/f587B9kaP0CPM3Q57EZTtK1X4GpQ1gYkI=; b=YaD82dR7dpbujd7Oo7hBG5kYoG/keLjxOw6JmlRaVW+Ot18CUDwGPQqnlBVi+60j8r0JmhxktUFnRhZ+KzCbsSE9rJ53ldICMcwyBgyQISbtqVIEqjRs29sm1tHg3cfz5UrumnsIL/iGYcHhnimFoEIT37Yrd4468biO6hPlvEp8xWCbtAhUKUdVYjL20mEvx7gBFC0g60vl9fmUpP2R4lXrgT5N21eNknLUOXy+yftqVfSg0lqwZl+wmBdASbUtmeuiG2w8zUh9ZgInqdt9nb75q0QUxTuH7dVPjvcw36/1ZuztzJmjJWnP/blxsyr99ZJIpGEpWFPBND3WvBeW+w==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqSI5-0002o0-Gu; Mon, 26 Feb 2018 15:34:41 -0800 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Mon, 26 Feb 2018 15:34:41 -0800 In-Reply-To: <41ac3ca1-a850-2c8a-0ad4-6b410b3932aa@cs.ucla.edu> X-Priority: 3 (Normal) Importance: Normal 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:223099 Archived-At: > On 02/26/2018 02:22 PM, Daniel Colascione wrote: >> On 12/31/1969 04:00 PM, Paul Eggert wrote: >>> On 02/26/2018 01:18 PM, dancol@dancol.org wrote: >>>>> Or, just turn the dump to a C file, then compile it >>>>> and do a second link.  Aside from (maybe hypothetical) C compiler >>>>> limits, that would be very portable. >>>> But not redumpable. >>> >>> Why couldn't it be redumpable? All that the user should need is a C >>> compiler. That's not unreasonable. >> >> I thought we had this argument back when we were talking about >> modules. I think it's unacceptable to require a C compiler and the >> presence of Emacs unlinked objects for the proper operation of an >> end-user feature. > > Although using a dumped Emacs is an end-user feature, dumping and > redumping are not. Dumping and/or redumping are techniques used to build > Emacs, and in practice they should be part of a software build system; > for such a thing it's reasonable to assume a C compiler. > > We already assume a C compiler (or equivalent) when building modules; we > don't assume a C compiler only when people are using the modules. > Dumping is similar. > >> >>>> Besides, the problem with a second link is that it might change the >>>> relative positions of symbols within Emac >>> >>> How could that be a problem? Symbols known to C code are known by >>> their fixed offsets and the second link wouldn't change these >>> offsets, and symbols not known to C code need to be reallocated >>> anyway during loading. >> >> The linker is what determines into-translation-unit offsets, not the >> compiler. The offsets are patched in at link time. There's no >> particular requirement to perform the link the same way every time. > > For Lisp symbols visible to C, Emacs master currently determines symbol > offsets at C-compile-time, not at link time. Does pdumper change this? > If so, how and why does it change this? And if not, then I don't see the > problem. The built-in symbols are in one big contiguous array. That's why the scheme works.