From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in Date: Thu, 11 Apr 2019 21:20:28 -0700 Message-ID: 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> <597d5c5a-f8c1-3b69-006d-6e3da4b1124d@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="184325"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , emacs-devel@gnu.org To: "Paul Eggert" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 12 06:20:47 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 1hEngC-000lnS-O0 for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 06:20:45 +0200 Original-Received: from localhost ([127.0.0.1]:58670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEngB-000725-L5 for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 00:20:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEng2-00070d-U8 for emacs-devel@gnu.org; Fri, 12 Apr 2019 00:20:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEng1-0005Ok-7y for emacs-devel@gnu.org; Fri, 12 Apr 2019 00:20:34 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38524) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEnfz-0005O0-9f for emacs-devel@gnu.org; Fri, 12 Apr 2019 00:20:32 -0400 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=2CQgmLILSeBDoaCW3DF1TNauyhB81Wr3hPtDPI7eK3M=; b=E1OTNS7Taf1oU9SiwE8FMiVQmSE04MmTandK9dg8nGaW2CYIVhPqZi9IChxaCz9ZPY3tx/1BcSNQ4WbXTmwE4y/8FBjN4Onk6QPNTU41GWSeGday/tXyNmiBTrBtwCI8fHz7pbvo9By9kckauqefNXdMk3PoB980kpwv0F/wUwl+z6IO8B4bDz6p3apKljpQdSAx+WCXByoEr+fBaoHhbH+vhLwShoWnsqEhY1R8L5l5GYYXBO0GnPwSVLpqXW2jKPQnaCBdNydivQ+o+Br5Zb8cHS5Yn5ziP+bDc1fY5l9bKLBm8f67lZEmd8yLcjNTmqr9re9lWWaoGcKr5KihpA==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEnfw-0006OM-5c; Thu, 11 Apr 2019 21:20:28 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Thu, 11 Apr 2019 21:20:28 -0700 In-Reply-To: <597d5c5a-f8c1-3b69-006d-6e3da4b1124d@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:235324 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. You're not capturing all the inputs into the build. What about the linker itself? What about arguments? What about the environment? Consider a difference in section alignment between two versions of a linker. Consider LTO, in which the differences may be even more drastic, since in this case, object files contain an IR and not even machine code. What are you going to do, fold into the hash the linker itself and all the code and data on which it depends? >> 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 :-). It is theoretical: I agree. Whether or not the array is folded into program code doesn't matter. >> 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. No, the temacs.in approach is *not* broken. temacs.in doesn't have to be identical to temacs in order for the scheme to work. The only requirement is that if something in the build environment or in Emacs itself changes incompatibly, then temacs.in changes. If the temacs.in scheme *were* to break, it would have to be in such a way that 1) some change in Emacs or the environment resulted in temacs.in_1 (before the change) and temacs.in_2 (after the change) having the same hash, but temacs_1 (before the change) and temacs_2 (after the change) being different in a way that breaks pdumper. Can you think of such a scenario? I prefer the temacs.in scheme because it's agnostic to whatever it is that the linker might be doing. It's future-proof. > 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. If you want to address the build time issue, just rewrite the fingerprint in place. I very strongly suspect that a simple volatile declaration will be sufficient to ensure that the fingerprint array is contiguous in the binary. We could even locate the array in temacs.in via brute-force search, substituting a well-known highly-unlikely byte sequence as the dummy fingerprint.