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: pdumper on Solaris 10 Date: Wed, 11 Dec 2024 11:29:03 +0000 Message-ID: <8734iumpbi.fsf@protonmail.com> References: <8634iyf257.fsf@gnu.org> <86ttbdewpr.fsf@gnu.org> <87jzc9i3in.fsf@protonmail.com> <87a5d4flos.fsf@yahoo.com> <8634iwcit2.fsf@gnu.org> <87v7vrqax6.fsf@yahoo.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="12531"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , gerd.moellmann@gmail.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 13:15:01 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 1tLLcK-00031e-Ir for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 13:15:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLLbk-0001tF-HX; Wed, 11 Dec 2024 07:14:25 -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 1tLKtx-0002oX-F6 for emacs-devel@gnu.org; Wed, 11 Dec 2024 06:29:09 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLKtv-00083W-PZ for emacs-devel@gnu.org; Wed, 11 Dec 2024 06:29:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733916545; x=1734175745; bh=DZC4gxi57orYad18O14wC95lPFY13kjDjXNNqb7Evcg=; 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=q2yN0+PpbFic4f3Qt06cy7SJnRwXfoj/l9XtnJwkikhk7scT9w6lltbW5bKMA+9oS 6DLupdVK850UDEc8EQ2lU0vRJ/wxl/3DjZdsmggx4RUkfqVztqqLMwX5c/E5BkG6Su XWVI7SZRlfTyQLh9xCptx8yebMUfa2e4PYZFlQVzhrdG704WeJmIvJZmF8nYSd9h9O /9N5EA1DmjxuhJNjIuiwnlh2n4alW+hmdUz7Pgns9KAO0JLFFqfekR0adpGpVTfAlD BW3VyHLaN8YwfB9mHN9C2guH3h+YJZn/sYHRcnOcLM5aTON/LKAkyuLWx6yyJdPqPV IyUmGXCe5XRdA== In-Reply-To: <87v7vrqax6.fsf@yahoo.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0e6d9d3c7951b9eb686364177d03155ce1597b90 Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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: Wed, 11 Dec 2024 07:14:20 -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:326347 Archived-At: "Po Lu" writes: > Eli Zaretskii writes: >>> From: Po Lu >>> Cc: Gerd M=C3=B6llmann , Eli >>> Zaretskii , >>> ali_gnu2@emvision.com, emacs-devel@gnu.org >>> Date: Tue, 10 Dec 2024 08:04:03 +0800 >>> >>> Pip Cet writes: >>> >>> > I was talking about the non-mps branch, yes. We should drop !USE_LSB= , >>> > which doesn't work in its original use case today and hasn't for a >>> > while. It does happen to work in the WIDE_EMACS_INT case, but that's= a >>> > fortuitous accident at best. >>> >>> I propose to make it work again. It ought to be a simple matter of >>> scanning stack slots twice, with and without tag bits. >> >> Patches to that effect will be welcome, thanks. > > Yes, like I said at the beginning of this (burgeoning) thread, I intend > to return to active Emacs development after the release of Emacs 30. That's great to hear, but I'd like to make a final (promise!) attempt to dissuade you from making this particular change ("fixing" the code to support !USE_LSB_TAG more often). The changes that are necessary concern the most delicate part of the garbage collector: ambiguous scanning needs to remove the tag (the easy part), and live_cons_p etc. have to be changed to allow for more offsets (we need to recognize pointers to &Lisp_Object + 4 as well as pointers to &Lisp_Object itself; I think this bug is already present on big-endian 32-bit builds utilizing WIDE_EMACS_INT, but no one's using that). I suspect other changes will be necessary (in particular, I expect breakage on systems that use the high byte of 64-bit pointers, as some Android systems do; I also expect there will be sign extension / zero extension problems). The pdumper code also needs to be studied carefully, and most likely changed. (Pure space and unexec will likely have gone away by then, but they would be affected, too). This is not a quick fix. What makes this code delicate is that it's very rare for a stack reference, particularly an unusual one, to be the last reference that keeps another object alive; even if we fail to recognize an ambiguous reference and free the object it refers to, the most likely outcome is an invisible UAF error, because we happen to use-after-free memory right after the garbage collection, and it'll still have the expected contents. This part of the garbage collector has long been in need of some work (we currently search the RB tree twice for every word, even though the second pass is usually unnecessary). Obviously, that will be harder if we change the code in other ways. The very best outcome of making the changes you propose is that no one will ever use the changed code; in that case, all that will be achieved is to add unused code to a function that's already hard to understand, and to make future changes that much harder. But that's not what I think will hapen. What I think will happen is that users will start or continue using !USE_LSB_TAG, try to switch to MPS, run into a problem, (hopefully) report a bug, and we won't be able to deal with that bug report because we're comparing a USE_LSB_TAG + MPS build to a !USE_LSB_TAG + !MPS one, and it'll be impossible to tell which of the two major changes are causing the problem. In other words, every person affected by your proposed changes will be unable to usefully test MPS. I think that's bad. If you insist on making the changes, please make sure there is a visible "feature" in the corresponding MPS build which will let us know that bug reports are useless and should be disregarded. I personally won't ask anyone to test MPS in a setting where they cannot usefully report bugs. Obviously, reducing the number of people who can usefully test MPS will make it slightly less likely it'll ever land. Pip