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: --with-native-compilation build failure on 32-bit systems Date: Thu, 18 Aug 2022 08:17:36 +0300 Message-ID: <838rnmceq7.fsf@gnu.org> References: <86k07nl9qe.fsf@phe.ftfl.ca> <87bksyc36k.fsf@gnus.org> <83h72lvf8g.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27586"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 18 07:19:37 2022 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 1oOXwO-0006xN-I8 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 07:19:36 +0200 Original-Received: from localhost ([::1]:32878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOXwM-0006G6-58 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 01:19:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOXug-0005VH-Ar for emacs-devel@gnu.org; Thu, 18 Aug 2022 01:17:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55898) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOXue-0001r4-Kd; Thu, 18 Aug 2022 01:17:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bLfywm0o0rBR3a1xx7Rw8C+2eEtz3iBeqEhaApuY8oo=; b=RUGE9+CESjeB b21tU1smTa5hyTzLFQSLZekfXVkNwbeXMIO5N4auJVirgevIQSsMnlwWldcthgZD+bnjZjCBuig9H MeVOJKB/OE9ao0yzX/5ywxeBLD8Er0cUGHdntNDHSF2ErBjuALNpHVrbeajXyJN/XLdApHJyKrH7R KjcOKF2NUVbc3ij0qu2SVi0y6+cJ2WjR8Ok7oQD19UL4GoF4XpqJwq9NLrAmOIDSJrZP95ezrNdXI sN9/cWeRYCfmF/uuSPZWHfmb4/j8OSiQNm3Ia8Ln40lQp9ROhwoc3RLinElQWWTUKNT+LB7D6Z9Si l2pnYb0TfsYseU6/DY+p6A==; Original-Received: from [87.69.77.57] (port=1271 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOXua-0007Wy-U1; Thu, 18 Aug 2022 01:17:46 -0400 In-Reply-To: (message from Andrea Corallo on Wed, 17 Aug 2022 19:59:59 +0000) 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" Xref: news.gmane.io gmane.emacs.devel:293582 Archived-At: > From: Andrea Corallo > Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org > Date: Wed, 17 Aug 2022 19:59:59 +0000 > > Okay, I had some time to work on this and this is what's going: > > After having loaded ediff-hooks temacs never sweeps vectors because, > even if call `garbage-collect' before dumping, this is inhibited cause > we overflowed purespace. > > Interestingly we warn for purespace overflow calling 'check_pure_size' > when dumping with unexec and not with pdumper. Given this makes the GC > not functional (at least in this phase) I'm wondering if we shouldn't do > this as well. I always thought that pure-space overflow with pdumper doesn't matter, that's why we don't warn. You seem to be saying that it does matter? By "makes GC not functional" do you mean during dumping, or do you mean after restarting Emacs with the pdumper file? > Also, thinking about the whole system even better, I think fixing-up CUs > reachable from named functions is definitely a bad for another reason > that is lambdas! We could have a lambda referenced somewhere that keeps > a CU loaded and we need to fix it up anyway before dumping. > > So yeah I guess tomorrow I'll prepare the patch were we keep a list of > loaded CU to fix-up. Thanks, but why does this only affect 32-bit builds?