5 ms·

Admittedly I only glanced at this, but why can't the process image in question be dumped to a C string (or .S file if you really want) and then linked with the

• rurban 10y ago
  That's what's need to be done on windows. The other dumpers can do better by just dumping the segments and loader commands, by taking special care of base address adjustments and restoring the old malloc'd heap structures, not be mixed up with the new heap. A normal linker will still need to reload the shared libs, and then adjust the external symbols there. Your solution needs several seconds, unexec just a few milliseconds.
  • haberman 10y ago
    Sorry, maybe I wasn't clear. I was suggesting doing all of this at build time, not runtime. Oh wait does this all get serialized to disk every time you exit emacs? Is that what I'm missing? If so, why not run the linker at emacs exit time, to optimize the loading sequence?
    • rurban 10y ago
      unexec is only done once, at build-time, to convert temacs with a bunch of loaded libraries to emacs, which includes those libraries already. So it doesn't need to search them on disc, and compile them. It's never serialized. It's just dumped. Like a core file, with just proper headers, sections and segments, so that it can be executed. A proper COFF/ELF binary. A core file has all the segments but misses the headers.
      • haberman 10y ago
        Ok, so why can't it just be dumped to a .S file, so the regular toolchain can handle creating the headers, sections, and segments? .S files basically let you create arbitrary ELF images without making you implement the ELF format yourself. I'm really not getting what the custom linker/toolchain in unexec is buying you.