From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
To: Andrea Corallo <acorallo@gnu.org>
Cc: "Gerd Möllmann" <gerd.moellmann@gmail.com>,
"Eli Zaretskii" <eliz@gnu.org>,
stefankangas@gmail.com, emacs-devel@gnu.org,
monnier@iro.umontreal.ca
Subject: Re: Merging scratch/no-purespace to remove unexec and purespace
Date: Thu, 19 Dec 2024 09:28:57 +0000 [thread overview]
Message-ID: <875xng9g48.fsf@protonmail.com> (raw)
In-Reply-To: <yp1v7vgaapz.fsf@fencepost.gnu.org>
"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.
> 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
next prev parent reply other threads:[~2024-12-19 9:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 10:47 Merging scratch/no-purespace to remove unexec and purespace Stefan Kangas
2024-12-17 13:12 ` Gerd Möllmann
2024-12-17 14:20 ` Gerd Möllmann
2024-12-17 14:30 ` Gerd Möllmann
2024-12-17 17:56 ` Gerd Möllmann
2024-12-17 18:50 ` Eli Zaretskii
2024-12-17 18:56 ` Gerd Möllmann
2024-12-18 12:55 ` Andrea Corallo
2024-12-18 14:03 ` Gerd Möllmann
2024-12-18 16:05 ` Pip Cet via Emacs development discussions.
2024-12-18 16:30 ` Gerd Möllmann
2024-12-18 16:25 ` Pip Cet via Emacs development discussions.
2024-12-18 22:27 ` Andrea Corallo
2024-12-19 9:28 ` Pip Cet via Emacs development discussions. [this message]
2024-12-19 10:38 ` Andrea Corallo
2024-12-19 10:50 ` Stefan Kangas
2024-12-19 12:08 ` Pip Cet via Emacs development discussions.
2024-12-19 17:55 ` Stefan Kangas
2024-12-19 20:13 ` Pip Cet via Emacs development discussions.
2024-12-20 15:59 ` Stefan Monnier
2024-12-20 16:22 ` Pip Cet via Emacs development discussions.
2024-12-20 17:25 ` Gerd Möllmann
2024-12-20 20:35 ` Andrea Corallo
2024-12-20 20:39 ` Pip Cet via Emacs development discussions.
2024-12-21 6:33 ` Gerd Möllmann
2024-12-21 6:56 ` Andrea Corallo
2024-12-20 20:38 ` Pip Cet via Emacs development discussions.
2024-12-20 20:57 ` Gerd Möllmann
2024-12-20 8:42 ` Pip Cet via Emacs development discussions.
2024-12-18 0:18 ` Stefan Kangas
2024-12-17 19:30 ` Helmut Eller
2024-12-17 20:47 ` Stefan Monnier
2024-12-18 2:15 ` Stefan Kangas
2024-12-18 7:11 ` Helmut Eller
2024-12-18 13:35 ` Pip Cet via Emacs development discussions.
2024-12-18 6:56 ` Helmut Eller
2024-12-21 17:41 ` Helmut Eller
2024-12-21 18:32 ` Gerd Möllmann
2024-12-22 1:28 ` Stefan Kangas
2024-12-18 9:30 ` Pip Cet via Emacs development discussions.
2024-12-18 0:50 ` Po Lu
2024-12-18 2:12 ` Stefan Kangas
2024-12-18 21:26 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xng9g48.fsf@protonmail.com \
--to=emacs-devel@gnu.org \
--cc=acorallo@gnu.org \
--cc=eliz@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=pipcet@protonmail.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.