[TUHS] Emacs and undump

[downing.nick@gmail.com (Nick Downing)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

I've been having a bit of trouble with /bin/sh (Bourne's original one)
for the same reason. I described my projects in more detail earlier,
but in a nutshell I have intercepted open() and other syscalls, and I
have implemented replacements so that old code like /bin/sh doesn't
have to change, it sees a pretty BSD-like system. So one thing I had
to do was check if the thing being opened is a directory, and if so I
vacuum up the contents using the modern readdir() supplied in glibc or
whatever, and then write a tempfile in a format which the old style
readdir() understands. Then I return a handle to the tempfile instead
of the directory. Trouble is, this makes a non-stdio-using program be
stdio-using, in the worst case it's a non-stdio-using program that has
its own malloc() based on sbrk()... so we get another malloc()
happening in the middle, I temporarily fixed this by redirecting the
modern system's malloc() into the ancient system's malloc() but this
is a very non desirable solution. As another possibility I was
thinking of changing the ancient system's sbrk() into realloc() and
implementing a routine to relocate the heap, it obviously would have
to understand everything on the heap and everything that can point
into it. It's a real mess. But ultimately if I could get this right, I
could implement a lightweight system with no memory manager where all
processes share the malloc().
cheers, Nick

On Mon, Feb 27, 2017 at 6:26 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
>> Tim Bradshaw wrote:
>>>> David wrote:
>>>> I remember that GNU Emacs launched the first time and then dumped
>>>> itself out as a core file. Each subsequent launch would then ‘undump’
>>>> itself back into memory. All this because launching emacs the first
>>>> time required compiling all that lisp code.
>>> It still works like that.  Indeed that's the conventional way that
>>> Lisp systems tend to work for delivering applications
>>
>> Emacs came from ITS, and many Lisps derive from Maclisp which also came
>> from ITS.  In ITS, it was common for applications to be dumped into a
>> loadable core image, even if they were written in assembly language.
>
> Unix systems are retiring sbrk(2), so emacs is breaking on those
> systems. Trouble is, sbrk is kinda hard to implement on systems that
> allocate memory for processes from multiple pools and other crazy
> things. So now Emacs has no way of knowing where the upper limit was
> so it can't start allocating with its own custom allocator...
>
> At least GNU Emacs...
>
> Warner