Re: MPS: Please check if scratch/igc builds with native compilation

[Helmut Eller]

On Wed, May 22 2024, Gerd Möllmann wrote:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>>> I've checked that d_reloc is indeed scanned by fix_comp_unit. The
>>> check gives me reasonable confidence that this "should work". But as
>>> an alternative, I also made all the things like d_reloc in the .elns
>>> ambiguous roots, so that they cannot possibly be moved, if all works as
>>> expected.
>>
>> Registering the dump as root happens rather late.  The relocation code
>> allocates a hash table and stores a reference to it in
>> comp_u->lambda_gc_guard_h.  By that time the dump should already be a
>> root.  Can we register the dump earlier?  AFAIU, the dumper writes zeros
>> in the cells for to-be-relocated references and the scan code will
>> ignore them.  So I think this could work:
>>
> AFAIU, at the point above the necessary relocations haven't yet been
> done, so the dump is still in its "raw" form as it is in the file. Which
> means, among other things, that Lisp_Objects haven't been changed to
> point to where the dump is mmap'd or where the data segment of Emacs is
> and so on. So I don't think that would work.

As I said: NULLs shouldn't cause any trouble.  The scan code ignores
that.  And pdumper_next_object seems to its own address calculations.

Can you try the patch?  (And perhaps delete ~/.emacs.d/eln-cache/* and
remove write permissions.  I've seem elns being loaded from there.
Which is not not good for repeatability.)

> But, what if we park MPS while we are loading the dump? WDYT?

Is it possible to allocate from a parked arena?