5 ms·

> it's a different world, and it has been different for a very long time, with software and OS/hardware significantly more decoupled. This argument makes about

• int_19h 10y ago
  Why? A binary executable does not rely on the very fine details of the implementation of the OS heap manager, for example, while a dump necessarily would.
  • sedachv 10y ago
    > A binary executable does not rely on the very fine details of the implementation of the OS heap manager, for example, while a dump necessarily would. What are you talking about? What is it about brk(2)/sbrk(2)/mmap(2) that would be a problem?
    • int_19h 10y ago
      Correct me if I'm wrong, but if you make a process dump of the entire process, that dump would include internal structures used to maintain its heap, no? If those structures change between OS versions, for example, then the process dump from an older version would represent corrupted heap when loaded on a newer version.
      • sedachv 10y ago
        None of the kernel data structures are saved or even visible to the process - the kernel memory (on Linux x64 everything mapped in the upper 128TiB) is not readable by the process. You can have a problem if the kernel system call interface changes, but that is a problem for every executable. You would need to re-compile everything on the system.
        • int_19h 10y ago
          Are all heap-related structures be stored in kernel memory, though? There's nothing in userspace for bookkeeping?
          • sedachv 10y ago
            The kernel just gives you pointers and sizes via mmap/sbrk, it is up to you to keep track of them.