From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in Date: Wed, 10 Apr 2019 20:31:48 -0700 Organization: UCLA Computer Science Department Message-ID: <064a6c19-760d-a2b6-8f9c-8f7972557b65@cs.ucla.edu> References: <20190409224339.20116.87667@vcs0.savannah.gnu.org> <20190409224342.0DA1F20E54@vcs0.savannah.gnu.org> <86697de6baf024290a9d0b10743ba2b7.squirrel@dancol.org> <9093e1cb-7cad-14df-9428-6229313e8f51@cs.ucla.edu> <7bd7a4577abcebd089c7aecc253718f2.squirrel@dancol.org> <0c98c320ec76444fb5af1971d8f99360.squirrel@dancol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="125954"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 11 05:32:45 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEQSC-000WZs-OF for ged-emacs-devel@m.gmane.org; Thu, 11 Apr 2019 05:32:44 +0200 Original-Received: from localhost ([127.0.0.1]:40975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEQSB-0001Bi-Nw for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 23:32:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEQRT-0001BR-N6 for emacs-devel@gnu.org; Wed, 10 Apr 2019 23:32:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEQRS-000478-Nr for emacs-devel@gnu.org; Wed, 10 Apr 2019 23:31:59 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52190) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hEQRS-00046N-Do for emacs-devel@gnu.org; Wed, 10 Apr 2019 23:31:58 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 78986161680; Wed, 10 Apr 2019 20:31:55 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XVMQCMzwnMV3; Wed, 10 Apr 2019 20:31:54 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A40DB161687; Wed, 10 Apr 2019 20:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WwGgobqdcyCT; Wed, 10 Apr 2019 20:31:54 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 82367161627; Wed, 10 Apr 2019 20:31:54 -0700 (PDT) In-Reply-To: <0c98c320ec76444fb5af1971d8f99360.squirrel@dancol.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:235268 Archived-At: >> checksumming the .o files ought to be enough to >> generate a fingerprint good enough for the intended purpose of the >> checksum. > > No: that's simply wrong. pdumper *does* care about the low-level layout of > objects within Emacs. We have dump-to-emacs relocations based on offsets > from a known symbol within Emacs. Ah, sorry, I didn't know that. > The linker deciding to lay out objects > within sections in a different order will break the dump. But why would the linker do that? It sounds like you're worrying that, even if we give the linker the same object files in the same order and ask it to link Emacs again, then the linker might generate a different executable, one that is incompatible with the previous one. But if that's the case, the temacs.in solution has the same problem so we're no worse off than before. And if it's not the case, then what exactly is the failure scenario here? I'm not seeing any failure scenarios for the current approach that can't also be failure scenarios for the previous approach, even now that I know that pdumper cares about object order within a section. >> The mechanism could also "break" with whole-program optimization that >> inlines the fingerprint array, or with other plausible future changes to >> linkers as they get smarter. > > The optimization you've described doesn't matter: as long as changing the > *value* of the fingerprint array (not its length!) preserves Emacs *object > layout* change in Emacs, we're good. The optimization I describe could migrate some or all of the fingerprint array's contents into the code, with the amount of migration depending on the contents of the fingerprint array, and with the migrated contents omitted from the fingerprint array. I don't see how object layout (in the sense that you describe) would be preserved in that scenario.