[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compiled lisp file format (Re: Skipping unexec via a big .elc file)
From: |
Ken Raeburn |
Subject: |
Re: compiled lisp file format (Re: Skipping unexec via a big .elc file) |
Date: |
Sun, 28 May 2017 07:07:15 -0400 |
On May 21, 2017, at 04:53, Paul Eggert <address@hidden> wrote:
> Ken Raeburn wrote:
>> The Guile project has taken this idea pretty far; they’re generating ELF
>> object files with a few special sections for Guile objects, using the
>> standard DWARF sections for debug information, etc. While it has a certain
>> appeal (making C modules and Lisp files look much more similar, maybe being
>> able to link Lisp and C together into one executable image, letting GDB
>> understand some of your data), switching to a machine-specific format would
>> be a pretty drastic change, when we can currently share the files across
>> machines.
>
> Although it does indeed sound like a big change, I don't see why it would
> prevent us from sharing the files across machines. Emacs can use standard ELF
> and DWARF format on any platform if Emacs is doing the loading. And there
> should be some software-engineering benefit in using the same format that
> Guile uses.
Sorry for the delay in responding.
The ELF format has header fields indicating the word size, endianness, machine
architecture (though there’s a value for “none”), and OS ABI. Some fields vary
in size or order depending on whether the 32-bit or 64-bit format is in use.
Some other format details (e.g., relocation types, interpretation of certain
ranges of values in some fields) are architecture- or OS-dependent; we might
not care about many of those details, but relocations are likely needed if we
want to play linking games or use DWARF.
I think Guile is using whatever the native word size and architecture are. If
we do that for Emacs, they’re not portable between platforms. Currently it
works for me to put my Lisp files, both source and compiled, into ~/elisp and
use them from different kinds of machines if my home directory is NFS-mounted.
We could instead pick fixed values (say, architecture “none”, little-endian,
32-bit), but then there’s no guarantee that we could use any of the usual GNU
tools on them without a bunch of work, or that we’d ever be able to use non-GNU
tools to treat them as object files. Then again, we couldn’t expect to do the
latter portably anyway, since some of the platforms don’t even use ELF.
Ken
- Re: Skipping unexec via a big .elc file, Philipp Stephani, 2017/05/01
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/05/01
- Re: Skipping unexec via a big .elc file, Daniel Colascione, 2017/05/18
- compiled lisp file format (Re: Skipping unexec via a big .elc file), Ken Raeburn, 2017/05/21
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Paul Eggert, 2017/05/28
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Ken Raeburn, 2017/05/29
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Paul Eggert, 2017/05/29
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Eli Zaretskii, 2017/05/29
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Paul Eggert, 2017/05/29
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Eli Zaretskii, 2017/05/29
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Paul Eggert, 2017/05/29
- Re: compiled lisp file format (Re: Skipping unexec via a big .elc file), Ken Raeburn, 2017/05/30