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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 19 Feb 2021 13:31:49 +0000
> Cc: akrl@sdf.org, 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.

Let's talk about *.elc files first, as this is not supposed to happen.
AFAIR, we write the bytecode into a temporary file, and then rename it
atomically only when the compilation finishes successfully.  So
interrupting should not do any harm, and therefore I'm curious what
kind of differences in *.elc files do you see in these cases.

> 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).

I'd suggest to start with master, as that is supposed to be much more
mature.  If that turns out to work correctly (and (IME it is), then we
could take a look at the native-comp branch, where there could be
problems we didn't yet fix.

In general, Make itself will delete any target files it knows about
that were not fully built at the time of SIGINT.  Maybe we don't tell
Make enough about the files native-comp produces?

> > > 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.)

I think it'd be interesting to know what code overflows the stack, if
it isn't GC.