Question

我从使用gdb分析的核心转储中获得了以下反汇编代码。

   0x083dc366 <+194>:   call   0x83db38e <Buf::push_data(UBYTE const*, UWORD)>  
=> 0x083dc36b <+199>:   mov    eax,esi  
   0x083dc36d <+201>:   mov    edx,DWORD PTR [ebp-0x1c]

是否有可能在第一个mov指令崩溃或者gdb中的小箭头不可信？

Answer 1

如果内存不可执行（例如跳转到碰巧解码为mov的数据字节），仅方式可能会在该特定指令上崩溃。因为看起来它来自正确的代码部分，所以在这种情况下不太可能。

我怀疑GDB只是向您展示函数调用返回的地方，并且实际崩溃发生在被调用函数内部。也许它无法访问函数的代码或者由于其他原因决定切换堆栈帧。使用bt检查完整堆栈跟踪，并在必要时使用frame #n切换帧。

在极端情况下，转储本身可能已损坏并包含错误信息。如果你可以可靠地重现崩溃，最好从一开始就在GDB下运行程序，并在它发生碰撞时立即捕获崩溃，然后才有可能破坏任何东西。

Answer 2

NO。

两个寄存器之间的移动不应该导致分段错误，因为寄存器不存储在存储器中但在CPU上具有特殊位置。 gdb中的箭头没有显示当前行，它显示指令指针的当前值，或者下一条要运行的指令，但之前的行可能尚未执行，因此它可能是崩溃的来源。 / p>

Answer 3

是否可能在第一个mov指令崩溃

没有

或来自gdb的小箭头不可信任

应该信任箭头。

最有可能的原因是你有“无意义”的数据：你已经重建了可执行文件，或者你给GDB提供了错误的可执行文件，因此崩溃的可执行文件在{{1}处有一个不同的指令来自你指向GDB的可执行文件。

可以通过寄存器到寄存器的mov指令发出信号11吗？

3 个答案:

NO。