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: Building scratch/igc with -fno-omit-frame-pointer Date: Sat, 28 Dec 2024 20:38:37 +0000 Message-ID: <87frm7ee7e.fsf@protonmail.com> References: <87frmjirum.fsf@no.lan> <87h66z8tqr.fsf@protonmail.com> <875xnf8oz1.fsf@protonmail.com> <86v7vekgcy.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="9552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , =?utf-8?Q?Gerd_M=C3=B6llmann?= , emacs-devel@gnu.org, eller.helmut@gmail.com To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 21:41: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 1tRdd8-0002Jg-Cg for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 21:41:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRdcW-0006fo-Py; Sat, 28 Dec 2024 15:41:14 -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 1tRdaD-0006K3-61 for emacs-devel@gnu.org; Sat, 28 Dec 2024 15:38:49 -0500 Original-Received: from mail-10629.protonmail.ch ([79.135.106.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRdaA-0002sN-Nc for emacs-devel@gnu.org; Sat, 28 Dec 2024 15:38:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735418322; x=1735677522; bh=tcF4BJiV1Bhs8v0whpOm7Mwxx8le+dkbL16apKBEkLk=; 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=JENNkbxYRUzmXVPBtvNJoDVqNSUyxZX0vlmTYY+17ykAOUClxlELE9ZwEVl2Nix0e m0H3Y8ue2VQAsNAzL2RzgLo4f5D53D1W+gXahcD4/7sJKE7Uhsv1mjV784FGAYJnGP ehIBAqhyRLcos7Ue7yD/fnHIAe+3MmTkXq8wmXbqtL7hFZT3CNCdYJm6dsm1O2k6UR B5v8cWehwic63umKxWwOhG+JRm4QOUcVEEX1AEGKaBEjeuwNu80I/Dt7Tf2+QlQZXL SNnm3/bBPEIYFAnthzkSqQw51K7+vRZAdcn5kvLVC5CATFbBK5z8NjeOotV9ZB+owA SEHX9LcQQKtZA== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1e78ef6bfb503c245b7106215972b7ba127ae701 Received-SPF: pass client-ip=79.135.106.29; envelope-from=pipcet@protonmail.com; helo=mail-10629.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_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: Sat, 28 Dec 2024 15:41:10 -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:327299 Archived-At: "Stefan Kangas" writes: > Eli Zaretskii writes: > >>> From: Gerd M=C3=B6llmann >>> Cc: "Pip Cet via \"Emacs development discussions.\"" , >>> Helmut Eller >>> Date: Thu, 19 Dec 2024 20:57:45 +0100 >>> >>> Pip Cet writes: >>> >>> > Gerd M=C3=B6llmann writes: >>> > >>> >> Pip Cet via "Emacs development discussions." >>> >> writes: >>> >> >>> >>> Does anyone remember what our conclusion was wrt >>> >>> -fno-omit-frame-pointer? I seem to remember there was a patch to M= PS to >>> >>> avoid relying on setjmp() to save all registers, but I'd still be >>> >>> happier if we enabled that for all MPS builds, since we don't know >>> >>> whether our MPS has the patch. >>> >> >>> >> I'm using -fno-omit-frame-pointer, but I don't remember why. I think >>> >> Helmut said something or so (in CC). >>> > >>> > We tried not using it, it caused a bug, I spent too many hours tracki= ng >>> > that one down, so now I think we should make configure.ac always enab= le >>> > it, even though it should be a no-op on some architectures (I think >>> > macOS on aarch64 is one of them). > > I took a look in the archives, and the reason is that there is a bug > with register scanning that -fno-omit-frame-pointer fixes: > https://github.com/Ravenbrook/mps/pull/38 Thanks! FWIW, I think this isn't a mistake in MPS. C libraries changed to "scramble" the stack pointer and base pointer in the jump buffer in setjmp(). They provided no good alternative way to do what MPS needs. Assembly register spilling isn't a good option. Emacs uses __builtin_unwind_init, FWIW. > diff --git a/configure.ac b/configure.ac > index 885075a2f1d..1d8f69ff119 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -5622,6 +5622,7 @@ AC_DEFUN > HAVE_MPS=3Dno > LIBMPS=3D > IGCOBJ=3D > +MPS_CFLAGS=3D > if test "${with_mps}" !=3D "no"; then > AC_CHECK_HEADER([mps.h], > [AC_CHECK_LIB([mps], [mps_arena_create], [HAVE_MPS=3Dyes], [], > [$LIB_PTHREAD])]) > @@ -5635,12 +5636,16 @@ AC_DEFUN > else > LIBMPS=3D"-lmps $LIB_PTHREAD" > fi > + # Force -fno-omit-frame-pointer to avoid MPS bug with register scann= ing: As explained above, I'd prefer not calling it "MPS bug". Let's just call it "bug"? Pip