GNU bug report logs -
#46495
28.0.50; [native-comp] Build fails for 32bit --with-wide-int
Previous Next
Full log
Message #148 received at 46495 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: dmalcolm <at> redhat.com, andrewjmoreton <at> gmail.com, 46495 <at> 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
This bug report was last modified 4 years and 43 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.