Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Kragen Javier Sitaker <kragen@canonical.org>
Newsgroups: comp.lang.c,comp.lang.lisp,comp.emacs
Subject: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)
Followup-To: comp.emacs
Date: Thu, 03 Sep 2026 14:37:53 -0300
Organization: Primarily biological and memetic
Lines: 31
Message-ID: <87v78mz15a.fsf_-_@debian>
References: <113ovuj$23t9c$1@dont-email.me> <114f9up$1mm0c$1@dont-email.me> <114ge0v$24ndu$2@dont-email.me> <114h1v7$2b0po$2@dont-email.me> <114h24r$9nm$1@reader1.panix.com> <114h26m$2b0po$3@dont-email.me> <114kain$3erqe$1@dont-email.me> <114oc02$qbqp$1@dont-email.me> <114odai$qp0b$1@dont-email.me> <114piou$14lmv$2@dont-email.me> <114pno3$16g53$1@dont-email.me> <114pqg5$17lne$1@dont-email.me> <5T_bS.71191$4Fu9.56234@fx05.ams4> <27248.58134.739884.512819@parhasard.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 03 Sep 2026 17:38:02 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="4101883"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19HbqPRR8mzbd4R8f/7cCiS"; posting-host="9d8b1d041ffbfb92fa0be79acc76e4c5"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:yKQhApySTa6fAyUEjkDltYoHAvo= sha1:dAOS7en1NwHG7glkAIec/Ob6FkA= sha256:EtOx+REmtfCfyMvDWei2b26gLtwZYttJpBIfcjJQJD0= sha1:kROM4ztGJ1kKzjPCFhfWxwI6LaY= sha256:f7zGuXUZvh5njjESeHO0V1lz0893cybespNfI3XktBI=
Xref: csiph.com comp.lang.c:401599 comp.lang.lisp:61623 comp.emacs:2572

Aidan Kehoe <kehoea@parhasard.net> writes:
> I haven’t gone into the weeds of the GNU Emacs native-compiled function
> implementation, but it has to be doing something similar. The functions are not
> in the data segment, they’re not in BSS, they’re not on the stack; that leaves
> the heap.

On amd64, at least, instead of running them from a heap, it seems to be
compiling elisp into .so files which it can then dlopen(), but it names
them `*.eln` instead of `*.so`:

    : ~; shuf -n 8 /proc/$(pidof emacs)/maps
    7f44e7cb3000-7f44e7cb4000 r--p 00005000 fe:01 1216485                    /usr/lib/x86_64-linux-gnu/libgpm.so.2
    7f44e8e34000-7f44e8e47000 r--p 00000000 fe:01 1212779                    /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12
    7f44c4151000-7f44c4154000 rw-p 00005000 fe:05 1323730                    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/nxml-parse-79a53381-b87f8800.eln
    7f44c74a5000-7f44c74bb000 rw-p 00006000 fe:05 1320433                    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/cc-vars-6cc3f0fc-a4ab31d9.eln
    7f44c544e000-7f44c5458000 rw-p 0000b000 fe:05 1323563                    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/with-editor-ad819b7b-2e1f7b93.eln
    7f44c5383000-7f44c5384000 r--p 0000d000 fe:05 1321666                    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/log-edit-bc58b2d4-860d5c35.eln
    7f44c52f5000-7f44c52f8000 r--p 00021000 fe:05 1323613                    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/magit-log-ffefa368-c52fff03.eln
    7f44c50a5000-7f44c50a8000 r-xp 00001000 fe:05 1321734                    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/xdg-9947111f-70cd76a9.eln
    : ~; file /home/user/.emacs.d/eln-cache/28.2-66fa0d00/nxml-parse-79a53381-b87f8800.eln /home/user/.emacs.d/eln-cache/28.2-66fa0d00/cc-vars-6cc3f0fc-a4ab31d9.eln /home/user/.emacs.d/eln-cache/28.2-66fa0d00/with-editor-ad819b7b-2e1f7b93.eln
    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/nxml-parse-79a53381-b87f8800.eln:  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ae37239bb67ec11b5d1eaf514df0660634fbd946, not stripped
    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/cc-vars-6cc3f0fc-a4ab31d9.eln:     ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=043e590c8a3917994270925abbfa6ec746488abb, not stripped
    /home/user/.emacs.d/eln-cache/28.2-66fa0d00/with-editor-ad819b7b-2e1f7b93.eln: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2bfb93008822275a66cad1c463d286f366388725, not stripped
    : ~; 

When I’ve disassembled these, they seem to indirect all their function
calls through a jump table, so that you can rebind existing symbols to
new functions and affect already-compiled code.  I haven’t dug into it
in much detail, though, so I might be mistaken.

Kragen