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 15:24:38 -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> 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="131764"; 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 00:25:18 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 1hEi8D-000Y9N-2q for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 00:25:18 +0200 Original-Received: from localhost ([127.0.0.1]:55708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEi8B-0007SK-TH for ged-emacs-devel@m.gmane.org; Thu, 11 Apr 2019 18:25:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEi7d-0007S7-ES for emacs-devel@gnu.org; Thu, 11 Apr 2019 18:24:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEi7c-0000yc-B3 for emacs-devel@gnu.org; Thu, 11 Apr 2019 18:24:41 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33432) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEi7c-0000wo-1m for emacs-devel@gnu.org; Thu, 11 Apr 2019 18:24:40 -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=P80gM/qfOQgVHKSo3xDVKmkSwuDP3gvbbwCugwsfZ5A=; b=DtgCc0IGr9xMccwHrrC83bDMpvcDZf9H1Yc8kCx/QAWtcoGVzuAQ+16DdsZMGK95W1IIEOOx64VIPyn/zqDdS5dMOl5ncVIPZ2oRf+qXkSdNO4RXXwWhaF5/C017QXhHkiq9N+lyxM28OyicCdKlbd/MxUjP8yfuu3K8gz4r+5m830LEQzUDlQEoc3Dr258HX7chm4ueZ/9KVeN5Uel6MICEMUHMa8CwQBjeQVHnAirBuBSMoJuWC6rwkZ1NOxFe/QWfAL1wGrOChxtAK2GeNu2ofHvLeetFDR94EDagAgnQTFjpba8IDD6FGj2axn83bViWu6KyR4ObIZSLk0jNRg==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEi7Z-00050W-U2; Thu, 11 Apr 2019 15:24:38 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Thu, 11 Apr 2019 15:24:38 -0700 In-Reply-To: <064a6c19-760d-a2b6-8f9c-8f7972557b65@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:235313 Archived-At: >> 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. Who knows what linkers might do? Change is especially likely in an LTO world when different linker flags or the linker binary changes? I want to future-proof the fingerprint mechanism by fingerprinting something as close as possible to the actual binary we run. > 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. 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. If we're worried about the array being folded into the code, we can make it volatile. If someone changes a linker flag that changes object ordering, temacs.in will change. If the linker gets upgraded and flips the order of two variables in .data, temacs.in will change. >>> 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. Even if the array is migrated into code, changes to linker configuration will still change the temacs.in fingerprint. The invariant here isn't that temacs.in has to be same as temacs, but rather that if temacs_1 differs from temacs_2 in ways that pdumper cares about, then temacs.in_1 must have hash different from temacs.in_2. My objection is that the object-hashing approach can result in a situation in which temacs_1 and temacs_2 differ in ways that pdumper cares about but nevertheless have the same fingerprint.