|
From: | Daniel Colascione |
Subject: | Re: Preview: portable dumper |
Date: | Fri, 16 Feb 2018 07:44:50 -0800 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Fri, 16 Feb 2018 07:10:42 -0800
>
> The original proposal I had in mind was to make a normal data array:
>
> uint8_t dump[15*1024*1024] = { embedded_dump_signature };
>
> And then refer to this array on code. No part of the toolchain is
> allowed to remove this array. The "dump insertion" procedure we're
> considering would just amount to changing the contents of this array in
> an already-linked executable using dumb find-and-replace anchored on
> embedded_dump_signature.
I can understand how rewriting the array could work (but we'd need to
know its size in advance, otherwise we'd waste memory, like Emacs on
w32 does today with its dumped_data array, especially since the size
during bootstrap needs to be so much larger than with byte-compiled
Lisp files).
But I'm not sure I understand how references to that
array in the code would work. Do you mean there would be a need to
"fix up" address references in the code as part of "dump insertion"?
If so, that's my original suggestion from 2 years ago, which was voted
down due to complexities.
> I like the idea of being able to mv emacs emacs.old, make emacs, and
> then have emacs.old and emacs still both run and work normally. I don't
> think the numbered build mechanism you fixed completely solves the
> problem, since it only works in one specific context.
I imagined the fingerprint we compute is already used (or can be used)
to reject dump files from a different build? If so, this could
provide at least some protection form calamities.
[Prev in Thread] | Current Thread | [Next in Thread] |