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: Thu, 11 Apr 2019 20:45:58 -0700 Organization: UCLA Computer Science Department Message-ID: <597d5c5a-f8c1-3b69-006d-6e3da4b1124d@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> <064a6c19-760d-a2b6-8f9c-8f7972557b65@cs.ucla.edu> 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="52736"; 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 Fri Apr 12 05:46:55 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 1hEn9T-000DcN-6r for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 05:46:55 +0200 Original-Received: from localhost ([127.0.0.1]:58411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEn9S-0008Bb-3d for ged-emacs-devel@m.gmane.org; Thu, 11 Apr 2019 23:46:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEn8h-0008BW-5R for emacs-devel@gnu.org; Thu, 11 Apr 2019 23:46:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEn8g-0002Bw-3D for emacs-devel@gnu.org; Thu, 11 Apr 2019 23:46:07 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36902) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hEn8d-00029n-TV for emacs-devel@gnu.org; Thu, 11 Apr 2019 23:46:04 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4DC1C1616AE; Thu, 11 Apr 2019 20:45:59 -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 5ZGZOxtr4Nrg; Thu, 11 Apr 2019 20:45:58 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 708261616E7; Thu, 11 Apr 2019 20:45:58 -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 7DVBz0x1x_KR; Thu, 11 Apr 2019 20:45:58 -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 45C5B1616D7; Thu, 11 Apr 2019 20:45:58 -0700 (PDT) In-Reply-To: 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:235323 Archived-At: Daniel Colascione wrote: >> 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 > > It's likely that the linker to lay out objects in a section identically in > two different builds when the only difference between the builds is the > content of an array. Sure, but it's even more likely for linkers to lay out objects in a section identically in two different builds when there is no difference whatsoever between the inputs to the builds. So I'm still not seeing the failure scenario for the current approach that wouldn't also be a failure scenario for the previous (temacs.in) approach. > If we're worried about the array being folded into > the code, we can make it volatile. That wouldn't be enough; we'd need the volatile accesses to memory under the program's control being tricky enough (they aren't now) so that the compiler couldn't optimize them away or reorder the array or whatever. Admittedly this is getting a little theoretical (but then this particular point is pretty theoretical anyway :-). > If someone changes a linker flag that > changes object ordering, temacs.in will change. Right, but that can also affect temacs in the previous approach; that is, temacs.in might be linked with different flags than temacs is. Or the linker might be upgraded between the time that temacs.in is built, and the time that temacs is built. So these failure scenarios apply to the previous approach too. If we rely on a fingerprint we have to give up on the idea of an ironclad guarantee that if the fingerprint matches, Emacs is compatible. We have to settle for just a high-enough probability in practice. We could document ways in which the low-probability events can occur (hash collision, linker change that breaks reproducible builds, etc.). Or we could change the pdumper so that it doesn't rely on a fingerprint: instead, Emacs could record a complete description of what it's assuming in the dump file, and check this description when it reads the dump back in. However, that'd be some work and is almost surely overkill.