From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Andrea Corallo <acorallo@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Merging scratch/no-purespace to remove unexec and purespace
Date: Thu, 19 Dec 2024 05:38:57 -0500
Message-ID: <yp1ed249cu6.fsf@fencepost.gnu.org>
References: <CADwFkmmX7pxzLCRU3aU=oZS1NRdVuxxU-JCHpO2=e3J-mRS55Q@mail.gmail.com>
 <m2ttb2fkkc.fsf@gmail.com> <m2ed26qjm2.fsf@gmail.com>
 <86seqmm9dq.fsf@gnu.org> <m2a5cuqgsk.fsf@gmail.com>
 <yp1bjx9b16y.fsf@fencepost.gnu.org> <m2pllprsuw.fsf@gmail.com>
 <87frml9cy4.fsf@protonmail.com> <yp1v7vgaapz.fsf@fencepost.gnu.org>
 <875xng9g48.fsf@protonmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="3766"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@gmail.com>,  Eli
 Zaretskii <eliz@gnu.org>,
 stefankangas@gmail.com,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca
To: Pip Cet <pipcet@protonmail.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 19 11:39:31 2024
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1tODwH-0000pi-E6
	for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Dec 2024 11:39:29 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1tODvs-0001tg-3c; Thu, 19 Dec 2024 05:39:04 -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 <acorallo@gnu.org>) id 1tODvq-0001s9-BN
 for emacs-devel@gnu.org; Thu, 19 Dec 2024 05:39:02 -0500
Original-Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@gnu.org>)
 id 1tODvp-0006Cx-9t; Thu, 19 Dec 2024 05:39:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=EaaM3Akz09/3ParbqM+HDeL1pyBfQeX61InR7+CxIFg=; b=av5F9PYJXeXymNNUQr0v
 itGCqASbLn4Xhn6LowbLK57PdzAmvfhlsWpEpdcJE34hpabbOwFHvQBjY9fonq1akz8Cnp3Zy1xWT
 C5+rHaU/VFVklfq/yykxezH69y6sLHbmGEnHBO2ZCts1h6458o3jjShKTRJC96TkETF53J4ftGIB2
 7X2/ASeHikyAxp/FSVMxCiNdc6mHQoXX6VXGUiMxQFKGYvehTv872hK77aldF7yCY25kfmijpbK/I
 W6N1bmsuH4KApe9Ixynr7l8S80ut30SfxVbdPfZhPYBOza0wUg8kbeb2H/tt2BCu2o77jH+8i/HhB
 2BBlPH+p8+bzYA==;
Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@gnu.org>)
 id 1tODvo-0006BC-Ad; Thu, 19 Dec 2024 05:39:00 -0500
In-Reply-To: <875xng9g48.fsf@protonmail.com> (Pip Cet's message of "Thu, 19
 Dec 2024 09:28:57 +0000")
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=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:326716
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/326716>

Pip Cet <pipcet@protonmail.com> writes:

> "Andrea Corallo" <acorallo@gnu.org> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>> Pip Cet <pipcet@protonmail.com> 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.

Correct, maybe we should use 'comp--lambda-fixup' so it's even more
evidently private to the compiler, not sure if would be worth using a
different kind of placeholder object.

>> 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.

master doesn't have forbidden symbols that can't be stored in data_vec
so why should we test for that?