我正在调试应用程序的 native C 库部分的崩溃，该部分是通过 JNI 从 Java 端调用的。
我找到了 Java 留给我的崩溃文件的这一部分:
# JRE version: 6.0_16-b01
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
# Problematic frame:
# C [binaryname.so+0x2760] functionname+0x59
我已经反编译了这个:
[richg@SVR-LRH-ES-2A]$ gdb binaryname.so
...
(gdb) disas 0x275e 0x2768
Dump of assembler code from 0x275e to 0x2768:
0x000000000000275e <functionname+87>: rex.RB clc
0x0000000000002760 <functionname+89>: movzbl 0x230(%rax),%eax
0x0000000000002767 <functionname+96>: test %al,%al
再次查看我的堆栈跟踪和寄存器部分，我可以看到:
RAX=0xffffffffffffffff, RBX=0x00002aab6cdf46c8, RCX=0x00002b70e0f15d73, RDX=0x000000005d5ffbe0
RSP=0x00000000463f9710, RBP=0x00000000463f9770, RSI=0x00002b70e0f27820, RDI=0x00000000463f9748
R8 =0x00002b70e0f27838, R9 =0x000000005cfa9828, R10=0x000000005cfa9478, R11=0x000000005cfa9440
R12=0x00002aab84654000, R13=0x00002aab6cdf46c8, R14=0x00000000463f9808, R15=0x00002aab84654000
RIP=0x00002aab79316760, EFL=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
所以 %rax 是 0xffffffffffffffff。我觉得这很可疑。
不过，我不久前就用尽了 x86 的知识。我读过一些关于 movz 的文章，我了解它的作用(通过用零填充低 24 位，将 8 位整数转换为 32 位整数)，但我仍然有疑问:
1) 调用中0x230部分的意义是什么？我可以在代码中看到 movzbl 的其他用法，其中有不同的数字。
2)我是否正确地认为，如果输入寄存器的值大于 8 位(这里是 %rax 的值)，那么这会因溢出而崩溃？ (如果是的话，这将是我崩溃的根本原因。)
3) 为什么 Java 给我的寄存器转储中没有 %eax？
最佳答案
0x230 是一个偏移量，0x230(%rax) 表示正常世界中的 [rax+0x230]。
所以 movzbl 0x230(%rax),%eax 最终意味着 movzx eax, byte ptr [rax+0x230]。
这里没有实际的输入寄存器，rax应该保存一个地址。 -1 作为地址看起来不太有效。这可能就是问题所在。
eax 当然在寄存器转储中 - 只需查看 rax 的下半部分即可。
关于java - movzbl 如何与寄存器值 0xffffffffffffffff 交互？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11582904/