使用in_asm时判断Qemu guest指令的来源
Determining the source of Qemu guest instructions when using in_asm
我正在尝试收集有关使用与执行的库代码百分比的统计信息。为此，我使用 -d in_asm 标志调用 Qemu-user。我将其记录到一个文件中，并得到一个相当大的文件，其中列出了翻译后的指令，如下所示
----------------
IN:
0x4001a0f1e9: 48 83 c4 30 addq [=11=]x30, %rsp
0x4001a0f1ed: 85 c0 testl %eax, %eax
0x4001a0f1ef: 74 b7 je 0x4001a0f1a8
----------------
IN:
0x4001a0f1f1: 49 8b 0c 24 movq (%r12), %rcx
0x4001a0f1f5: 48 83 7c 24 50 00 cmpq [=11=], 0x50(%rsp)
0x4001a0f1fb: 0f 84 37 01 00 00 je 0x4001a0f338
----------------
为了将块映射到相关文件，我提取了 qemu 进程的 /proc/pid/maps 并将执行的指令地址与来宾程序中文件的地址范围进行比较。这似乎工作得相当好，但是执行的大部分指令似乎都在映射文件中包含的任何文件之外。底部嘉宾地址space 罗列如下
.
.
.
40020a0000-4002111000 r--p 00000000 103:02 2622381 /lib/x86_64-
linux-gnu/libpcre.so.3.13.3
4002111000-4002112000 r--p 00070000 103:02 2622381 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
4002112000-4002113000 rw-p 00071000 103:02 2622381 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
4002113000-4002115000 rw-p 00000000 00:00 0
555555554000-5555555a1000 r--p 00000000 103:02 12462104 /home/name/Downloads/qemu-5.2.0/exe/bin/qemu-x86_64
来宾程序似乎在 0x4002115000 结束，来宾程序与从 0x555555554000 开始的 Qemu 之间有相当大的差距。我可以将库中的指令与实际的二进制文件相匹配，因此这种方法并非完全错误。然而，有将近 60,000 个块被执行，其起点在 0x400aa20000 和 0x407c8ae138 之间。这个内存区域名义上是未映射的，但 Qemu 似乎正在翻译并成功执行此处的代码。该程序似乎 运行 正确，所以我不确定这些指令的来源。我最初认为它可能是 vDSO，但范围似乎太大了，而且有太多单独的地址。我查看了其中几个块的前面代码，它在 ld.so 中，但我不能说是否所有调用都在那里生成。我认为这可能是内核代码，但我不确定如何验证这是否属实。我不知道如何解决这个问题。
有没有办法追溯这些指令的天意？也许使用 gdb 存根或其他一些日志记录功能？"
当您在 /proc/pid/maps 中搜索时，相应的模块可能已经卸载。 运行 LD_DEBUG=files <your qemu command line> 将打印模块加载信息，包括它们的加载地址和大小。在那里搜索缺少的代码地址。
我正在尝试收集有关使用与执行的库代码百分比的统计信息。为此，我使用 -d in_asm 标志调用 Qemu-user。我将其记录到一个文件中，并得到一个相当大的文件，其中列出了翻译后的指令，如下所示
----------------
IN:
0x4001a0f1e9: 48 83 c4 30 addq [=11=]x30, %rsp
0x4001a0f1ed: 85 c0 testl %eax, %eax
0x4001a0f1ef: 74 b7 je 0x4001a0f1a8
----------------
IN:
0x4001a0f1f1: 49 8b 0c 24 movq (%r12), %rcx
0x4001a0f1f5: 48 83 7c 24 50 00 cmpq [=11=], 0x50(%rsp)
0x4001a0f1fb: 0f 84 37 01 00 00 je 0x4001a0f338
----------------
为了将块映射到相关文件，我提取了 qemu 进程的 /proc/pid/maps 并将执行的指令地址与来宾程序中文件的地址范围进行比较。这似乎工作得相当好，但是执行的大部分指令似乎都在映射文件中包含的任何文件之外。底部嘉宾地址space 罗列如下
.
.
.
40020a0000-4002111000 r--p 00000000 103:02 2622381 /lib/x86_64-
linux-gnu/libpcre.so.3.13.3
4002111000-4002112000 r--p 00070000 103:02 2622381 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
4002112000-4002113000 rw-p 00071000 103:02 2622381 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
4002113000-4002115000 rw-p 00000000 00:00 0
555555554000-5555555a1000 r--p 00000000 103:02 12462104 /home/name/Downloads/qemu-5.2.0/exe/bin/qemu-x86_64
来宾程序似乎在 0x4002115000 结束，来宾程序与从 0x555555554000 开始的 Qemu 之间有相当大的差距。我可以将库中的指令与实际的二进制文件相匹配，因此这种方法并非完全错误。然而，有将近 60,000 个块被执行，其起点在 0x400aa20000 和 0x407c8ae138 之间。这个内存区域名义上是未映射的，但 Qemu 似乎正在翻译并成功执行此处的代码。该程序似乎 运行 正确，所以我不确定这些指令的来源。我最初认为它可能是 vDSO，但范围似乎太大了，而且有太多单独的地址。我查看了其中几个块的前面代码，它在 ld.so 中，但我不能说是否所有调用都在那里生成。我认为这可能是内核代码，但我不确定如何验证这是否属实。我不知道如何解决这个问题。
有没有办法追溯这些指令的天意？也许使用 gdb 存根或其他一些日志记录功能？"
当您在 /proc/pid/maps 中搜索时，相应的模块可能已经卸载。 运行 LD_DEBUG=files <your qemu command line> 将打印模块加载信息，包括它们的加载地址和大小。在那里搜索缺少的代码地址。