Re: [feature/native-comp] breakage on build

[Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>]

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>>
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>
>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>>>>
>>>> Yes, libgccjit is not needed for loading elns.  There might be some minors to
>>>> look at as I've never tested this configuration but should be no
>>>> problem.
>>>
>>>
>>> For an Emacs compiled --with-nativecomp, how do I stop it attempting to
>>> native compile?
>>
>> `comp-deferred-compilation'
>>
>> But I was wrong there's another issue.  If we can't compile we cannot
>> synthesize trampolines, as a consequence we can't redefine or advice
>> primitive functions reliably... Sorry
>
>
> I didn't think we could do this anyway. I guess this means that
> native-compiled lisp to primitive adviced functions will skip the
> advice? So, that would be a change from the current situation where
> C calls to C functions don't get adviced, but lisp calls to C functions
> do.

Apologies let me be more precise.

- Advising C to C primitives is not possible in both implementations

- With bytecode you can effectively redefine primitives with _no_
  dedicated op-bytecode.

- With native code you can redefine all of these except for the (very
  few) primitives we open-code directly in the generated code.  This is
  a smaller set than the previous one but still not perfect.

  Anyway, we can do this but relying on this trampoline syntheses
  mechanism.

  Removing this mechanism is therfore ATM not possible, unless we
  precompile all trampolines AOT bug#44238.  This should be rather easy
  tho, we lack only some integration into the build system lets say.


  Andrea