bug#46502: 28.0.50; [feature/native-comp] (d3a399dd) native-comp bootstrap failure

[Pip Cet]

On Thu, Feb 18, 2021 at 2:33 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Thu, 18 Feb 2021 10:14:24 +0000
> > Cc: Michael Welsh Duggan <mwd@md5i.com>, 46502@debbugs.gnu.org
> >
> > One thing I've noticed in my experiments is that many builds that are
> > interrupted at the wrong point and then resumed produce different
> > results. I.e. you type "make", then hit Ctrl-C at the wrong time, then
> > type "make" again and you get a different result.
>
> What does "different result" mean in this case? is the produced .eln
> file different? or something else?

There are differences both in the .elc and .eln, and I saw different
success/failure behavior but only with local modifications. It's
possible that this is all harmless, but I have the bad habit of
assuming I can just type "make" again and have it resume an
interrupted build, and that certainly does not work on the native-comp
branch (I'm not sure it works on the master branch).

Note that all this is in serial builds. That parallelized builds are
unpredictable is a different issue entirely.

> > BTW, I'm also seeing very deep recursion when building the nativecomp
> > branch
> How do you see that?

Stack overflows in a limited-stack environment, even with the GC code
modified to allocate stack space more efficiently.

> And what code recurses so deeply?

Unfortunately, the environment I'm playing with doesn't have very good
backtrace facilities. (This is WebAssembly run by the Mozilla jsshell,
which has a small-ish stack size limit. I'll try finding what limits
the reported backtrace depth and disabling it.)