bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com
> Date: Fri, 05 Mar 2021 19:22:34 +0000
> 
> What we have as a doc is directly in the docstring of
> `comp-libgccjit-reproducer', I guess we could improve it.
> 
> Essentially having it bound to t while compiling produces a C file
> deposed where the .eln target directory.

The reproducer file is attached.  It is large, so I compressed it.
Let me know if you see there anything that could explain the problem.

> This file ELNFILENAME_libgccjit_repro.c can be just compiled linking
> against libgccjit to obtain the reproducer.

"To obtain the reproducer" meaning that the compiled and linked
program should crash in the same way is Emacs does?  I thought we
crash while compiling the file and linking it to produce a shared
library, not while running it.  Right?

> libgccjit should never segfault so if this crashes is clearly a bug.

Let's see what you can find in the reproducer file.

Meanwhile, I see that:

 . the file has DOS CRLF end-of-line format, because libgccjit opens
   the reproducer file in the default text mode
 . the file includes control characters: ^A, ^B, ^M, and others --
   what are those for?  I hope we cannot have ^Z there, because AFAIK
   text-mode writes will stop at the first such byte

More generally, what is the relation between the contents of the
reproducer file and the source the native compilation sees when we
call gcc_jit_context_compile_to_file?  Do we submit a similar file to
GCC or something?  IOW, can any weird characters I see in the
reproducer be relevant to the actual compilation (and thus to the
crash)?

Thanks.

subr-x-02dfef32-17faeb1d_libgccjit_repro.c.xz
Description: Binary data