From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: --with-native-compilation build failure on 32-bit systems Date: Wed, 17 Aug 2022 19:59:59 +0000 Message-ID: References: <86k07nl9qe.fsf@phe.ftfl.ca> <87bksyc36k.fsf@gnus.org> <83h72lvf8g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2810"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 22:02:06 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 1oOPEr-0000VR-D2 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 22:02:05 +0200 Original-Received: from localhost ([::1]:42876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOPEp-0007gv-Ia for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 16:02:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOPD6-0006t3-VH for emacs-devel@gnu.org; Wed, 17 Aug 2022 16:00:17 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:49786) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOPD4-0007Y2-4U; Wed, 17 Aug 2022 16:00:16 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 27HJxxhA029934 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 17 Aug 2022 20:00:00 GMT In-Reply-To: <83h72lvf8g.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 14:16:47 +0300") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:293573 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: Joseph Mingrone , emacs-devel@gnu.org, emacs@FreeBSD.org >> Date: Tue, 09 Aug 2022 09:21:11 +0000 >> >> > It looks to me like a GC bug so far. Unfortunatly I've very constrained >> > time to dedicate on this this week. >> >> Thinking about this... Maybe relying on the GC for this is not a very >> good idea in the first place. If we are conservative on the stack my >> might always mark a CU accidentally and fall into the same issue. >> >> I think we should maintain a list of all loaded CUs so we can fix them >> up reliably. If this is agreed not to be a bad idea I'll prepare a >> patch. > > I suggest to postpone the decision until we have a good understanding > of what happens in this particular case and why it happens only in > 32-bit builds. Maybe we will decide what you suggest, but there are > likely other factors at work here, and it would be good to know what > they are. > > Thanks. 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. 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. Best Regards Andrea