From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Merging scratch/no-purespace to remove unexec and purespace Date: Thu, 19 Dec 2024 09:28:57 +0000 Message-ID: <875xng9g48.fsf@protonmail.com> References: <86seqmm9dq.fsf@gnu.org> <87frml9cy4.fsf@protonmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40434"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , stefankangas@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 19 11:58:52 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tOEF1-000AID-Fu for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Dec 2024 11:58:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOEEd-0008Fi-6c; Thu, 19 Dec 2024 05:58:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOCqC-0000CW-3T for emacs-devel@gnu.org; Thu, 19 Dec 2024 04:29:08 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOCqA-0000fO-5L; Thu, 19 Dec 2024 04:29:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734600542; x=1734859742; bh=eKjCKpfBekeTSvobHEA5rDpSZwgEyS4bYVN5kgNhquU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=pPCmzAGQGU3EVMqbJfHC/Yx7NI/tgAJPoDI0CyinWNBvK3T4Zy52cTCytpRLYXcbi /p0JZysYepcVlb+l1kJNi0b1EubsbjBghil5aJhk5drePBtteYgkdkaarPfHQYfM/n wjJf+D3II9YjHHOyyZPK8YjbL4X9PxXeptsy3QmnMCGWTSvEnUoHvOsMERzKJ4NfbD eZf4kQlAD5EyT2JQ69ldgZk3i/Xs3Sk5ont+8OspnKZxfUp523Rs7GtewTMsHTNr6Q ja1o8gJiCvG8pOPnaiUnzX1pqzs8wLABKnQMiyeKOjnZKKy6SVmrDlKr5zHO2MVBMy 7QGioK+z1ttow== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 9a92b529955d25ad8dc3a87fa4f68bfe8855baf6 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 19 Dec 2024 05:58:25 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326721 Archived-At: "Andrea Corallo" writes: > Pip Cet writes: > >> Pip Cet writes: >>> IOW, the old code happened not to run into this problem because >>> lambda-fixup was pure, and we never applied the sanity checks to the >>> pure section. >> >> Just to be clear: the code on master is fine. I misunderstood it when >> modifying it for purespace removal, resulting in my bug which Gerd >> discovered and fixed. The code on no-purespace is also fine now, but >> it's Andrea's call whether he wants some of the checking code restored, >> and how. >> >>> My suggestion is to fix the "sanity check" on the master branch, change >>> it to apply to pure relocs there, and restore the fixed check on >>> scratch/no-purespace afterwards. >> >> Please ignore that. My suggestion is to EXTEND the sanity check on the >> master branch to cover pure and impure relocs, and restore the EXTENDED >> check before merging scratch/no-purespace. >> >> There is no bug to fix on master. > > Right your analysis is correct, the new code in the branch just made the > symbol 'fixup-lambda' not compilable. > > I restored the check and applied a variant of your fix with a comment > around. scratch/no-purespace work for me now. Just to summarize this: There's now a forbidden symbol, --lambda-fixup. If you use this symbol in your code and compile the code with nativecomp, that may appear to work, but loading the resulting object file into another Emacs will crash that Emacs, if that Emacs was built with checks enabled. > On master I don't think I see what we should do and the motivation for. The scratch/no-purespace branch now tests things more rigorously than the master branch does: master performs three checks on all impure relocations and a single check on pure ones, but scratch/no-purespace performs all three checks on all relocations. That means when we merge scratch/no-purespace, and hit one of the new assertions, it may be (and was, in Gerd's case) because the test would have failed on the master branch but was never performed there, and that would be unrelated to purespace removal. What I think we should do doesn't really matter, but it seems quite obvious to me that we should make the code on the master branch perform all three checks on all relocations, as the code on no-purespace does. Pip