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 14:13:11 +0000 Message-ID: <87bjxil35f.fsf@protonmail.com> References: <8634iyf257.fsf@gnu.org> <8634iwex8q.fsf@gnu.org> <86wmg7bso1.fsf@gnu.org> <865xnrbh3r.fsf@gnu.org> 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="11610"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , stefankangas@gmail.com, luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 16:48:19 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 1tLOwk-0002qY-Eu for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 16:48:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLOvg-0003MW-5o; Wed, 11 Dec 2024 10:47:12 -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 1tLNSo-0007t7-Rb for emacs-devel@gnu.org; Wed, 11 Dec 2024 09:13:19 -0500 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLNSm-0006pr-LV for emacs-devel@gnu.org; Wed, 11 Dec 2024 09:13:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733926393; x=1734185593; bh=NHG6cq7sRNlRRtYX0vfLxLGxE9S0VNiioIf1DEsI91Q=; 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=KyO/bFPDVlICsbMfHPOMQ8dZJm37EGE71PgHkVrdOeqsSsnYY2SalvmnK7PPE49Tr YREomFDtOt0SurFg/KgwV8hbImjTXZARb+Bgk+q+pcXlrKIgjcnetLWZsLrumQsfU/ PKTNs6go7PU/BTRgQEbjEKsuRY67Pnn8kgt80yLk2/IZe/rnQqHPdXfYToi9ovrM84 0xU7SYP1tGp4RAUSY2gcMwjsWKTjK751Qgk8MYaY8cMmgG44/wrrV3hYoy5LvSjT5y X7cm5ufp4+nfr8jfhyTzu5M64qfv22jBLYuGlp+yI5yZvNJb8LOz6e/3+t8ogAaVnj 8tKlSRDVsP1fQ== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4892ac78d31c49dc04a4a15244fc2c468aaefd42 Received-SPF: pass client-ip=185.70.43.16; envelope-from=pipcet@protonmail.com; helo=mail-4316.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_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=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 11 Dec 2024 10:47:09 -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:326362 Archived-At: Pip Cet writes: > Gerd M=C3=B6llmann writes: >> Eli Zaretskii writes: >>> That's not what Gerd says, AFAIU. But if you are right, then how >>> about making the WIDE_EMACS_INT configuration on the igc branch use >>> USE_LSB_TAG in the HAVE_MPS code branch? I can volunteer to test such >>> a build, if that would help. > > Thanks for the offer. I definitely think we should move away from > USE_LSB_TAG=3D0 as much as possible, and if the only place where such a > change would not be vetoed is scratch/igc + WIDE_EMACS_INT, we can at > least fix it there. If any issues arise, of course, it will be more > difficult to ascertain whether they were caused by the USE_LSB_TAG > change or the IGC changes themselves. > > So I'll push that change in a bit, unless someone objects. Just pushed it to the scratch/igc branch. It shouldn't have any effect on ordinary 64-bit builds; some of the code is to cater to the hypothetical big-endian 32-bit use case, and technically the x86 MPS weak pointer "optimization" could bite us again, but recent GCC does not generate the precise instructions that MPS emulates, so I'll risk it. As I've just explained, bug reports for the WIDE_EMACS_INT case will be difficult to deal with, as there are two major changes; let's see what happens, but I suspect we'll end up having to ask users to build a !MPS + USE_LSB_TAG + WIDE_EMACS_INT configuration. Pip