gdb如何在共享库函数中设置软件断点? [英] How does gdb set software breakpoints in shared library functions?

问题描述

我知道可执行文件中的软件断点可以正常工作将汇编程序指令在所需的位置替换为另一条，这会导致中断.因此，调试器可以完全在此位置停止执行，并将此指令替换为原来的指令，并询问用户下一步的操作或调用一些命令等.

I know that software breakpoints in an executable file can work through replacing some assembler instruction at the desired place with another one, which cause interrupt. So debugger can stop execution exactly at this place and replace this instruction with original one and ask user about what to do the next or call some commands and etc.

但是这种可执行文件的代码未被其他程序使用，并且在内存中只有一个副本.软件断点如何与共享库一起工作?例如，如果我在C库的某些内部功能中设置一个，那么软件断点将如何工作(据我所知，它对所有应用程序都只有一个副本，因此我们不能只替换其中的某些指令)?有没有用于此目的的软件断点"技术?

But code of such executable file is not used by another programs and has only one copy in memory. How can software breakpoints work with a shared libraries? For instance, how software breakpoints work if I set one at some internal function of C-library (as I understand it has only one copy for all the applications, so we cannot just replace some instruction in it)? Are there any "software breakpoints" techniques for that purpose?

推荐答案

Linux的答案是Linux内核实现了COW(写时复制):如果写入共享库的代码，则内核会首先是共享页面的私有副本，然后将内部虚拟内存仅用于该过程重新映射到该副本，并允许应用程序继续运行.这对于用户级应用程序是完全不可见的，并且完全在内核中完成.

The answer for Linux is that the Linux kernel implements COW (Copy-on-Write): If the code of a shared library is written to, the kernel makes a private duplicate copy of the shared page first, remaps internally virtual memory just for that process to the copy, and allows the application to continue. This is completely invisible to userland applications and done entirely in the kernel.

因此，直到第一次将软件断点放入共享库之前，它的代码确实是 shared ；但是之后，不是.此后，该过程将使用肮脏但私有的副本进行操作.

Thus, until the first time a software breakpoint is put into the shared library, its code is indeed shared; But afterwards, not. The process thereafter operates with a dirty but private copy.

此内核魔术使调试器不会导致其他所有应用程序突然停止.

This kernel magic is what allows the debugger to not cause every other application to suddenly stop.

但是，在像VxWorks这样的OS上，这是不可能的.根据个人经验，当我为VxWorks实现GDB远程调试服务器时，我不得不禁止用户在 semTake()和 semGive()中单步执行(OS信号灯功能)，因为a)GDB在其源代码级单步实现中使用软件断点，并且b)VxWorks使用信号灯来保护其断点列表...

On OSes such as VxWorks, however, this is not possible. From personal experience, when I was implementing a GDB remote debug server for VxWorks, I had to forbid my users from ever single-stepping within semTake() and semGive() (the OS semaphore functions), since a) GDB uses software breakpoints in its source-level single-step implementation and b) VxWorks uses a semaphore to protect its breakpoints list...

令人不愉快的结果是中断风暴，其中的断点将导致中断，并且在此中断中将存在另一个中断，并且在无法逃避的链中甚至对Ctrl-Z也存在另一个中断.唯一的解决方法是关闭机器电源.

The unpleasant consequence was an interrupt storm in which a breakpoint would cause an interrupt, and within this interrupt there would be another interrupt, and another and another in an unescapable chain resistant even to Ctrl-Z. The only way out was to power off the machine.

这篇关于gdb如何在共享库函数中设置软件断点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！