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: Wed, 10 Apr 2019 13:56:06 -0700 Message-ID: <0c98c320ec76444fb5af1971d8f99360.squirrel@dancol.org> 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> 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="154918"; 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 Wed Apr 10 22:56:23 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 1hEKGa-000e6o-9j for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 22:56:21 +0200 Original-Received: from localhost ([127.0.0.1]:37775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEKGZ-0008Fv-Af for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 16:56:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEKGQ-0008FE-JX for emacs-devel@gnu.org; Wed, 10 Apr 2019 16:56:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEKGP-0007T3-DC for emacs-devel@gnu.org; Wed, 10 Apr 2019 16:56:10 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39772) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEKGO-0007Sh-IQ for emacs-devel@gnu.org; Wed, 10 Apr 2019 16:56:09 -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=nMk88UrpVahKR/qWnswVli8s1Dr66ShWt2+y22hZgCE=; b=CvBOzp/c3CvIquCh46x0jinVcZkg/1f/1P3fr4HHoSMN/9CofOuahgDWjm1VjdA45fos0SouvfsbQkMw/o/cKB8tRm2VxRjcgyuB9oN/jmHp3tNa15r4TZJknWM7Jno911N4LL7wtUST7Pgcg8/TIJcRD0h7yZKzwDCW8idBkDbj6/AAlzK2jC0zPdeCIFLR2msMTScuXOPwDcUgO6Y3/hKlZOxBQma1wfx4xSTJioWylNSvdJMuOZ3g5ueOLLG94iVooI+hiT1BzRbJuQQJtuwV1qFnLOywp1W4pHyuS5sSJ12a2WX+7TnLqUwYhE4s4cuWL4FB/1Nq6DArwz1DUg==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEKGM-0006Y5-IA; Wed, 10 Apr 2019 13:56:06 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Wed, 10 Apr 2019 13:56:06 -0700 In-Reply-To: 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:235256 Archived-At: > On 4/10/19 12:42 PM, Daniel Colascione wrote: >> PIE and shared libraries are irrelevant. The whole point of pdumper is >> to >> be invariant across different PIE and DSO configurations. > > Yes, and that's part of the point. Because the pdumper doesn't care how > 'write' is implemented so long as it's done correctly, the fingerprint > doesn't need to include a checksum of the implementation of 'write'. > There's a good chunk of the Emacs executable that is in the same > category as 'write' - that is, the chunk doesn't matter for the purposes > of the fingerprint. Whether we checksum the irrelevant chunk is a > pragmatic/efficiency issue; it's not needed for correctness. > > With this in mind, checksumming the .o files ought to be enough to > generate a fingerprint good enough for the intended purpose of the > checksum. The checksum won't capture how 'write' is implemented, nor > will it capture detailed decisions about how the linker lays out Emacs's > low-level objects, but that's OK: the pdumper doesn't care about those > things so long as they're done correctly. 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. The linker deciding to lay out objects within sections in a different order will break the dump. We don't care how the linker lays out the object so long as it's the same in the binary that makes a dump and the binary that loads the dump. Your change makes it possible for incompatible Emacs binaries to have the same fingerprint. >> The temacs.in mechanism >> covers all current and *and unknown future* binary layout modifications. >> It breaks only if linker symbol arrangement depends on randomness or on >> the precise content of the fingerprint array, and both of these >> possibilities are unlikely. > > 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. > But none of this should matter, as any such > "breakage" should be irrelevant to the pdumper. It's quite relevant. Please either revert the temacs.in removal patch or implement the inline fingerprint stamping I described. The way you've left it is broken.