我知道可执行文件中的software breakpoints 可以通过将所需位置的一些汇编指令替换为另一条指令来工作，这会导致中断。所以调试器可以在这个地方完全停止执行，并用原来的指令替换这个指令，并询问用户下一步要做什么或调用一些命令等。
但是这样的可执行文件的代码不被其他程序使用，并且在内存中只有一个副本。 软件断点如何与共享库一起工作？例如，如果我在 C 库的某些内部函数中设置一个软件断点（据我了解，它对于所有应用程序只有一个副本，所以我们不能只替换其中的一些指令）？有没有为此目的的“软件断点”技术？
【问题讨论】：
标签： debugging gdb shared-libraries breakpoints internals
Linux 的答案是，Linux 内核实现了 COW（Copy-on-Write）：如果写入共享库的代码，内核首先制作共享页的私有副本，重新映射内部虚拟内存只为那个进程复制，并允许应用程序继续。这对用户级应用程序完全不可见，并且完全在内核中完成。
因此，直到第一次将软件断点放入共享库中，其代码才真正共享；但是之后，不是。此后该过程使用脏但私有的副本进行操作。
这种内核魔法使调试器不会导致所有其他应用程序突然停止。
但是，在 VxWorks 等操作系统上，这是不可能的。根据个人经验，当我为 VxWorks 实现 GDB 远程调试服务器时，我不得不禁止我的用户在 semTake() 和 semGive()（操作系统信号量函数）内单步执行，因为 a) GDB 在它的源代码级单步实现和 b) VxWorks 使用信号量来保护它的断点列表...
不愉快的后果是一个中断风暴，其中一个断点会导致一个中断，在这个中断中会有另一个中断，一个又一个在一个无法逃避的链中，甚至可以抵抗 Ctrl-Z。唯一的出路是关闭机器。
【讨论】：