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.