1. 如何将coredump文件恢复为进程？ #

首先得明确一个核心点：coredump是进程崩溃瞬间的静态状态快照，它记录了当时的内存数据、寄存器值、调用栈等信息，但并不是进程的“可恢复存档”——所以你没办法直接把它变回一个正在运行的进程，毕竟崩溃时进程已经终止，很多动态上下文（比如打开的文件、网络连接、内核态的资源关联）都已经丢失了。

不过你可以通过调试工具来模拟进程的状态，进行分析甚至尝试有限的恢复：

• 最常用的方式是用调试器加载coredump结合可执行文件：比如lldb -c my_core_dump ./my_executable，这样LLDB会把可执行文件的代码、调试信息和coredump的状态结合起来，让你可以查看崩溃时的调用栈、变量值、寄存器状态，就像进程刚崩溃时你立刻附加上去一样。
• 如果想要尝试让进程“恢复运行”，有一些小众工具（比如基于CRIU的扩展，但CRIU本身是针对进程 checkpoint/restore，和coredump不是一回事）可以尝试从coredump重建内存镜像，再结合可执行文件启动进程，但这种方式局限性极大——因为coredump没有记录进程的所有动态资源状态，恢复后的进程大概率无法正常运行，只能用于特定场景下的调试。

2. 远程机器能否完成进程重载？以及LLDB加载coredump后expr命令无效的问题 #

远程完成重载的可行性 #

可以，但得满足几个关键条件：

• 环境一致性：远程机器的操作系统、CPU架构必须和生成coredump的机器完全一致（比如都是x86_64的Ubuntu 22.04，或者相同版本的macOS），否则可执行文件和coredump的二进制格式不兼容。
• 文件完整性：远程机器需要有完全相同版本的可执行文件（编译选项、代码版本都不能变），以及对应的DWARF调试信息文件（如果调试信息没有嵌入在可执行文件里的话）。你可以把本地的这些文件传到远程，或者通过LLDB的远程调试功能加载本地文件（但网络传输大文件可能慢）。
• 调试方式：如果你的“进程重载”是指加载coredump进行分析，那远程操作很简单——要么把文件传到远程后直接在远程用lldb -c加载；要么在远程启动lldb-server，本地LLDB连接到远程服务器，然后加载远程的coredump和可执行文件。如果是更复杂的恢复运行操作，那远程机器需要支持对应的工具，且同样要面对coredump本身的局限性。

LLDB加载coredump后expr命令无效的原因与解决办法 #

这是个很常见的post-mortem（事后调试）问题，原因在于：
当你附加到运行中的进程时，LLDB可以利用进程的活跃执行环境——它能注入代码、修改内存，甚至临时执行表达式对应的代码；但加载coredump时，LLDB处于静态分析模式，没有活跃的进程上下文，自然无法创建执行表达式所需的运行环境。

解决办法有这些：

• 优先用frame variable代替expr：frame variable是直接从coredump的内存快照中读取变量值，不需要执行任何代码，在事后调试中可靠性高得多。比如想看my_var的值，直接敲frame variable my_var就行，比expr my_var靠谱。
• 尝试有限的expr使用：如果一定要用expr，尽量写简单的表达式（比如直接访问变量成员，不要调用函数、不要做复杂计算），并且确保你的DWARF调试信息完整正确——LLDB有时候可以通过模拟内存状态来支持简单表达式，但成功率不高。
• 极端情况的 workaround：如果必须执行复杂表达式，可以考虑把coredump的内存镜像恢复到一个和原环境一致的虚拟机/容器中，重新启动进程并附加LLDB，但这个操作复杂度很高，只适合特殊场景。

内容的提问来源于stack exchange，提问作者Karl