Re: --with-native-compilation build failure on 32-bit systems

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Joseph Mingrone <jrm@ftfl.ca>, 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