[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA7aPHhVBQrD8CZWjApQhQEG9sB1q1m+JzrymZom=c6dbQJpUQ@mail.gmail.com>
Date: Tue, 3 Feb 2015 07:21:38 -0500
From: stephen Turner <stephen.n.turner@...il.com>
To: musl@...ts.openwall.com
Subject: Re: GNU Emacs LD_PRELOAD build hack
On Feb 2, 2015 10:54 PM, "Rich Felker" <dalias@...c.org> wrote:
>
> Background: GNU Emacs' build process depends on the ability of the
> build-stage binary (temacs) to "dump" itself to a new executable file
> containing preloaded lisp objects/state in its .data segment. This
> process is highly non-portable even in principle; in practice, the big
> issue is where malloc allocations end up. They need to all be
> contiguous just above the .data/.bss in the original binary so that
> they can become part of the .data mapping. Against musl's malloc, this
> has two major ways it can fail:
>
> 1. musl uses mmap for large allocations (roughly, > 128-256k) and has
> no mechanism for obtaining such large objects from the main
> brk-based heap or even requesting such (whereas glibc has mallopt
> and/or an environment variable to control the mmap threshold, and
> emacs cheats and uses that to control glibc).
>
> 2. musl reclaims the gaps around the edges of writable mappings in the
> main program and shared libraries and uses them for malloc. If
> these are in shared libraries, they won't be dumped at all, and if
> they're in the main program, they actually overlap with .text on
> disk (the same page is mapped twice; this is the cause of the gaps)
> and thus the .text, not the heap data, gets written out to disk by
> the dumper.
>
> Emacs provides its own malloc replacement and tries to use it by
> default, but this has to be disabled with musl, since replacing malloc
> in dynamic programs doesn't work (and static binaries don't work right
> at all with emacs' dumper because libc state would get included in the
> dump -- state which is "intentionally lost" when it resides in a
> shared library whose state isn't dumped).
>
> The right solution: As I discussed on the emacs-devel list nearly a
> year ago, the right solution is to get rid of the non-portable code in
> emacs, dumping the lisp heap and its data (rather than the whole
> program) to a file and either mmapping it at runtime (and possibly
> relocating pointers in it, if the new location it's loaded at differs)
> or converting it to a C source file that's compiled and linked and for
> which the (static or dynamic) linker can perform relocations at
> link/load time. This solution also solves a number of other serious
> issues related to the dumper, including its incompatibility with PIE
> binaries.
>
> Unfortunately, the right solution requires a significant overhaul by
> someone with expertise in emacs internals, and it's not practical in
> the short term. Meanwhile, we have users wanting emacs on musl-based
> distros (myself included).
>
> So, here's an alternate solution.
I think there was a guy on the toybox list working on editors and might
have a emacs for you. Onefang comes to mind.
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
