bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Tue, 25 Jan 2022 13:49:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You mean, the breakpoint in maybe_defer_native_compilation never
> > breaks?  That in itself is probably a sign of some problem.
> 
> This is what I do and see:
> 
> -> gdb ./emacs RET
> GNU gdb (GDB) 11.1
> Copyright (C) 2021 Free Software Foundation, Inc.
> [...]
> Reading symbols from ./emacs...
> (gdb) break maybe_defer_native_compilation RET
> Breakpoint 1 at 0x400241af0: file comp.c, line 5104.
> (gdb) run -Q RET
> Starting program: Z:\pathto\bin\emacs.exe -Q
> [New Thread 9392.0x3f84]
> [New Thread 9392.0x5758]
> [New Thread 9392.0x1d48]
> [New Thread 9392.0x53e8]
> [New Thread 9392.0x51b0]
> 
> Thread 1 hit Breakpoint 1, maybe_defer_native_compilation 
> (function_name=0xffff81f161684338, definition=0x1e782a44035) at comp.c:5104
> 5104      if (!load_gccjit_if_necessary (false))
> (gdb)
> 
> 'Thread 1 hit Breakpoint 1' starts when I try to 'C-x C-f' a .tex file
> in Emacs.  And then I can use n, s within the debugger.  But I don't get
> any error and such.  Does this make sense to you?  I'm not really
> familiar with GDB.

Step through the code of maybe_defer_native_compilation with the 'n'
command, and see if it calls native--compile-async in this fragment:

  /* This is so deferred compilation is able to compile comp
     dependencies breaking circularity.  */
  if (!NILP (Ffeaturep (Qcomp, Qnil)))
    {
      /* Comp already loaded.  */
      if (!NILP (delayed_sources))
        {
          CALLN (Ffuncall, intern_c_string ("native--compile-async"),
                 delayed_sources, Qnil, Qlate);
          delayed_sources = Qnil;
        }
      Fputhash (function_name, definition, Vcomp_deferred_pending_h);
      CALLN (Ffuncall, intern_c_string ("native--compile-async"),
             src, Qnil, Qlate);
    }

If the code exits the function before getting to this place, try to
figure out why.  It could fail to load libgccjit DLL, here:

  if (!load_gccjit_if_necessary (false))
    return;

Or it could exit due to one of the following conditions:

  if (!native_comp_deferred_compilation
      || noninteractive
      || !NILP (Vpurify_flag)
      || !COMPILEDP (definition)
      || !STRINGP (Vload_true_file_name)
      || !suffix_p (Vload_true_file_name, ".elc")
      || !NILP (Fgethash (Vload_true_file_name, V_comp_no_native_file_h, Qnil)))
    return;

Or it could exit because it doesn't find the Lisp source file:

  Lisp_Object src =
    concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
             build_pure_c_string (".el"));
  if (NILP (Ffile_exists_p (src)))
    {
      src = concat2 (src, build_pure_c_string (".gz"));
      if (NILP (Ffile_exists_p (src)))
        return;
    }

Does one of these early returns indeed happen?

If not, i.e. if the code indeed calls native--compile-async, then you
should see a subprocess being started: native--compile-async calls
comp-run-async-workers, which calls make-process.  The code is in
comp.el.  If the subprocess is started, then JIT native-compilation
does work, and the question is what happens with the produced *.eln
files.