From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS signals and Emacs Date: Mon, 22 Apr 2024 17:42:33 +0300 Message-ID: <86frvd5uhy.fsf@gnu.org> References: <878r16n5jl.fsf@gmail.com> <87ttjulb16.fsf@gmail.com> <86a5ll7wj9.fsf@gnu.org> <71431fc4-2ab2-4778-88df-25d4e315d737@cs.ucla.edu> <87edaxlc93.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25136"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org To: eggert@cs.ucla.edu, Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 22 16:43:36 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 1ryutM-0006LF-JZ for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Apr 2024 16:43:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryusS-0000Pm-Ds; Mon, 22 Apr 2024 10:42:40 -0400 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 1ryusQ-0000PN-5v for emacs-devel@gnu.org; Mon, 22 Apr 2024 10:42:38 -0400 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 ) id 1ryusP-0002r0-8q; Mon, 22 Apr 2024 10:42:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=AYs9U4zvsI3kM4KD+2evLlrbtQeq/CtfJdueUQBRMNw=; b=BC1Wsz/HNBmyhe6b6xkb imWsQKttYzVLfGfC7EcpPgYfY9Dkihqf8+nKr7Xzp+y2iWMX0pSum4X1gCfgzL2fIWXZMKolYTSfa IHMRGbwuEwi4PODGZslWUkLGquEausyLg9n7+W4R52Fh7IS+uAJXoFLpShn1t9sKG+N/2kpPPcDj7 iL59WYM8636cu/QOCtUujlo9f5fgsNIUaBa3OyIBW8o/jiyZ0gLvvAxpLciOOCEbzxC7/kKYTjvhk k1N8nEfz4feXEhq+StEWTNqbfill8CLQhs1JOyft87P+BNRBhiP+c7l+jfKWkPfaZeJCwmwsEn2ns G2hnrflVl3qdOA==; In-Reply-To: <87edaxlc93.fsf@gmail.com> (message from Helmut Eller on Mon, 22 Apr 2024 16:10:00 +0200) 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:317980 Archived-At: > From: Helmut Eller > Cc: Eli Zaretskii , Gerd Möllmann > , > emacs-devel@gnu.org > Date: Mon, 22 Apr 2024 16:10:00 +0200 > > I was also puzzled by the fact that during pdump, sigHandle worked fine > but later during loaddefs-gen not. I then found this comment in > init_signals: > > /* Don't alter signal handlers if dumping. On some machines, > changing signal handlers sets static data that would make signals > fail to work right when the dumped Emacs is run. */ > if (will_dump_p ()) > return; > > That explains the puzzling behavior but it makes me wonder what kind of > machine that could possibly be. Also MPS clearly has to install memory > barriers, will_dump_p or not. Will that affect those machines? I think we only need to avoid installing signal handlers when dumping using unexec, because with pdumper we don't dump the data of signal handlers. Paul, am I right? If I'm right, the will_dump_p call should be replaced with will_dump_with_unexec_p (which is not relevant to the MPS branch anyway).