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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

Yes, the compiled program when executed will replay the same compilation
attempted by Emacs and therefore if is a libgccjit fault it should
crash.

Does the reproducer crash when executed on your system?

>> libgccjit should never segfault so if this crashes is clearly a bug.
>
> Let's see what you can find in the reproducer file.

Thanks, I'm going to have a look if I can reproduce here.

> 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?

The reproducer file is a file that is meant to recreate the same
libgccjit IR and attempt a compilation with that.  In practice it calls
the same functions we call at the interface with libgccjit describing
the code we want to compile and attempt to perform a compilation.

> IOW, can any weird characters I see in the
> reproducer be relevant to the actual compilation (and thus to the
> crash)?

I'm not sure why these characters are there but I don't think they are
relevant to the crash.

Thanks!

  Andrea