bug#58318: 28.2; Emacs installed from package won't work with MinGW

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, corwin@bru.st, bartosz.bubak@gmail.com,
>>         58318@debbugs.gnu.org
>> Date: Fri, 07 Oct 2022 12:35:52 +0000
>>
>> >> > Maybe there's a misunderstanding of what you meant by "if a compiler
>> >> > isn't present".  By "the compiler" do you mean libgccjit, or is it GCC
>> >> > and Binutils (or maybe all 3 together)?  IOW, are you talking about
>> >> > the ability to load existing *.eln files, or are you talking about the
>> >> > ability to both load existing *.eln files and produce new ones?
>> >>
>> >> I'm talking about trampolines, nothing else.
>> >
>> > Trampoline generation requires all the 3 components to be present,
>> > AFAIK.  Andrea, am I right?
>>
>> AFAIU only libgccjit and Binutils are necessary, but libgccjit *is* GCC
>> (in the sense another frontend fo the GNU Compiler Collection).  I
>> *think* gcc the binary (read the C frontend) should not be required.
>> But I don't know how distros package libgccjit and gcc, there might be
>> some dendency I'm not aware of.
>
> I didn't mean gcc, I meant cc1.  But maybe libgccjit can play its
> role, I don't know.
>
>> > If it indeed doesn't work (and I wasn't aware it didn't work), we
>> > should try fixing it, if that is feasible.
>>
>> Yes because `yes-or-no-p' is a primitive, so with no trampolines its
>> redefinition is not functional.
>>
>> A quick ad-hoc fix for `yes-or-no-p' is attached.  It does not have a
>> perf impact as `yes-or-no-p' will have to wait for the user input
>> anyway, if okay I can push it.
>
> What about other primitives? fset can be used for more than just this
> one.
>
>> Oherwise another strategy would be to disable direct calls from lisp
>> native code into primitives on Windows, this indeed has a performance
>> impact.
>
> How is this relevant only to Windows?

Windows is the only system where a native compiled Emacs can start even
if libgccjit is not present.  On GNU/Linux we get and error at load time
from the dynamic linker in case.  As a consequence on GNU/Linux Emacs is
always capable of producing trampolines when needed.

> And what do you mean by "disable direct calls from Lisp native code
> into primitives"?  I don't think I understand what this would do in
> practice.

Native compiled elisp calls directly into primitive functions not to go
through funcall.  For this reason when a primitive is redefined we need
to produce a trampoline in order to forward these calls to the funcall
machinery.  If we disable all of this optimization the issue disappears
but indeed that's not good from a performance point of view.

Indeed the other option is to precompile all trampoline AOT when we know
libgccjit is available.  It is actually very simple with something like:

(mapatoms (λ (f)
            (when (subr-primitive-p (symbol-function f))
              (or (comp-trampoline-search f)
                  (comp-trampoline-compile f)))))

It was not consired worth as trampoline production is very quick, but
might be worth at least for Windows platforms for the discussed reason.

  Andrea