emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On elisp running native


From: Eli Zaretskii
Subject: Re: On elisp running native
Date: Sat, 28 Dec 2019 15:34:00 +0200

> From: Andrea Corallo <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sat, 28 Dec 2019 11:57:36 +0000
> 
> Every .el file is compiled into a .eln.  This is technically a shared
> library.
> 
> Into the .eln Emacs is expecting to find a bunch of symbols.  Two of
> these are used for relocating objects and Emacs primitive functions.  So
> Emacs essentially writes some pointers into them.

Can you tell more about this part?  What does this relocation include,
and to what extent the details depend on the .eln file being in ELF
format?

> Then there's 'top_level_run'.  This is a real function that is responsible for
> modifying the environment as the execution of the various top level forms
> on the original .el file would do.
> 
> Emacs jumps into 'top_level_run' and this will call back into Emacs for
> evaluating forms and/or defining native functions (effectively new
> subrs).  This function is obviously not called when resuming from an
> image dump.

So when Emacs calls a Lisp function foo-bar, that call will produce a
call to 'top_level_run' function of the corresponding .eln file, and
then 'top_level_run' of that .eln will call the code produced from
'foo-bar'?  How does Emacs know which .eln "provides" foo-bar?

And how would the code in the .eln know to call back into Emacs?  When
you compile the native code, do you leave the symbols of Emacs
functions unresolved, and rely on the dynamic linker to resolve them?
If so, this doesn't work on Windows: you will get link errors.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]