[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58318: 28.2; Emacs installed from package won't work with MinGW
From: |
Andrea Corallo |
Subject: |
bug#58318: 28.2; Emacs installed from package won't work with MinGW |
Date: |
Fri, 07 Oct 2022 13:04:55 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, (continued)
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW,
Andrea Corallo <=
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Corwin Brust, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Corwin Brust, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07