bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org
>> Date: Tue, 30 Mar 2021 19:19:12 +0000
>>
>> >> `batch-native-compile' or `batch-byte-native-compile-for-bootstrap'
>> >> should be equivalent here as the second is just a way to do only byte
>> >> compilation for non dumped files when we are not using NATIVE_FULL_AOT.
>> >
>> > Then I guess I'm missing something: how does Emacs know whether a
>> > given .eln file should be saved in native-lisp/ or in
>> > ~/.emacs.d/eln-cache/?
>>
>> Ops apologies you are correct, `batch-byte-native-compile-for-bootstrap'
>> also select as destination folder the `native-lisp' directory in the
>> build tree.  It is correct to invoke
>> `batch-byte-native-compile-for-bootstrap' if we want the .eln to be
>> deposed there.
>
> OK, thanks.
>
> Another nit: the doc string of comp-debug says:
>
>   0 no debugging output.
>     This is the recommended value unless you are debugging the compiler 
> itself.
>   1 emit debug symbols and dump pseudo C code.
>   2 dump gcc passes and libgccjit log file.
>   3 dump libgccjit reproducers.
>
> But comp.c does this:
>
>   if (comp.debug)
>       gcc_jit_context_set_bool_option (comp.ctxt,
>                                      GCC_JIT_BOOL_OPTION_DEBUGINFO,
>                                      1);
>   if (comp.debug > 2)
>     {
>       logfile = emacs_fopen ("libgccjit.log", "w");
>       gcc_jit_context_set_logfile (comp.ctxt,
>                                  logfile,
>                                  0, 0);
>       gcc_jit_context_set_bool_option (comp.ctxt,
>                                      GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES,
>                                      1);
>       gcc_jit_context_set_bool_option (comp.ctxt,
>                                      GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING,
>                                      1);
>     }
>   [...]
>   if (comp.debug)
>       gcc_jit_context_dump_to_file (comp.ctxt,
>                                   format_string ("%s.c", SSDATA (ebase_name)),
>                                   1);
>
> AFAIU, this means the libgccjit log file is only output with
> comp-debug 3 and higher?

Correct, the docstring wasn't correct :/ aa159bf696 should update it to
reflect the current situation.

> Also, does comp-debug = 3 indeed cause the
> reproducer to be written, or is that controlled independently by
> comp-libgccjit-reproducer?

The reproducer is controlled independently by
`comp-libgccjit-reproducer', the idea behind this is that we want to be
able to produce reproducers independently from the debug settings (we
might have a ligccjit bug that is related to one debug option).

>
> And finally, what do you think about moving the
> gcc_jit_context_dump_to_file call to comp-debug 2 or higher?  IOW,
> make level 1 just add debug info to the *.eln files?  Especially if we
> are going to make comp-debug = 1 the default (as I think we should),
> wouldn't it be better than the current setup?  Or maybe we should
> introduce an intermediate debug level between the current 0 and 1?

My proposal would be like:

0 none
1 debug symbols
2 debug symbols + pseudo C file
3 debug symbols + pseudo C file + GCC passes + libgccjit log file

I think the backtrace issue you are facing is clearly a gdb unwinder
limitation on Windows that should be fixed in gdb.  OTOH I understand we
can't update gdb for all users that might want to help debugging an
issue, but I don't like very much the idea to have comp-debug 1 as
default on every system.  What about having 1 as default only on
Windows?  WDYT?

> And if we make that change, do we also need to bump the ABI number?

I should not be necessary.

Thanks

  Andrea