Re: Loading tramp for dump goes into infinite regress

[Andrea Corallo <akrl@sdf.org>]

Lynn Winebarger <owinebar@gmail.com> writes:

> On Sun, Jul 24, 2022 at 12:31 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Lynn Winebarger <owinebar@gmail.com>
>> > Date: Sun, 24 Jul 2022 12:20:47 -0400
>> > Cc: michael.albinus@gmx.de, emacs-devel@gnu.org
>> >
>> > it seems like something undesirable is going on between dumping and
>> > the native compilation unit.
>>
>> I find this hard to believe.
>
> If I can recreate it in a more direct way on my personal machines, I'll put in a bug with details including the required
> modifications to tramp.el (to remove the problematic require of tramp-loaddefs).
> I also observed the same problem/fix with:
>   gnus/message
>   progmodes/gdb-mi
>   calc/calc-ext
>   gnus/gnus-sum
>   gnus/gnus-art
> More troublesome, though is that emacs segfaulted when it attempted to load nxml/rng-pttrn, whether loading
> native-compiled, byte-compiled, or source.
>
> Otherwise, I was able to resolve the various issues (including some extensive surgery on vc/ediff-X files to stamp out
> the circular loading).  I am going to have to do a real bootstrap to avoid the "incoherent eln" error, though, and
> somehow force native compilation for all the libraries loaded in the dump (that are not on the compiler's "forbidden"
> list, anyway).
>
>> Btw, you are aware that dumping *.eln files basically dumps just their
>> names, not their code?  And that, when you start Emacs after dumping,
>> it will load all of those *.eln files one by one, which takes time
>> (*.eln files are just shared libraries, like *.so files), and use up
>> shared-library and handle slots of the Emacs process?  So I'm not even
>> sure doing this would make sense from the performance POV: it could be
>> that startup will slower, not faster.
>
> I am aware that dumping the eln files produces an indirection to the shared library, but not the details of the
> implementation.
> I would expect (or at least hope) that the effect of the evaluation that is done on loading to be stored in the dump and
> for the shared libraries to get loaded into the process without repeating the evaluation.  So things like the order of
> customization groups should be fixed.

While resurrecting from a dump an eln is mapped into memory if (at
least) a native compiled function noted in the dump was loaded from it.
So yeah the dumped state is preserved a no top level re-evaluation is
happening.

BTW I think so far we do not support re-dumping Emacs twice with native
code.  This is not a deep technical limitaiton, it's only because how we
fixup relative eln paths to support installed and non installed builds,
we should probably work on this limitation...

BR

  Andrea