使用 objdump 查找目标文件的偏移量
在尝试查找特定偏移量对应的目标文件的代码时，我有点困惑。偏移量为0xB71B13E8
使用proc/，我发现目标进程的libX11库的文本代码被映射到0xB70CC000-0xB71B7000 区域。
我现在想使用 objdump 在 X11 lib /usr/lib/libX11.so.6.2.0 的目标文件上找到此偏移量。
我应该查看 0xB71B7000 - 0xB71B13E8 = 0x5C18 还是 0xB71B13E8 - 0xB70CC000 = 0xE53E8 ？
我的另一个问题如下： libX11 库的文本代码所在的 0xB70CC000-0xB71B7000 区域大小为 0xEB000 字节。但是，当我 objdump /usr/lib/libX11.so.6.2.0 时，我可以看到从 0xA3517 到 0x135C0 的偏移量（即只有 0x8FF57 >）。这有什么理由吗？
提前致谢。
I am a bit confused while trying to find the code of an object file in which a particular offset corresponds to. The offset is 0xB71B13E8
Using proc/<PID>/maps, I found out that the text code of the libX11 lib for the target process was mapped on the 0xB70CC000-0xB71B7000 region.
I now want to find this offset on the object file of the X11 lib /usr/lib/libX11.so.6.2.0 using objdump.
Should I look into 0xB71B7000 - 0xB71B13E8 = 0x5C18 or into 0xB71B13E8 - 0xB70CC000 = 0xE53E8 ?
Another question that I have is the following:
The 0xB70CC000-0xB71B7000 region in which the text code of the libX11 lib resides is of 0xEB000 bytes. However, when I objdump /usr/lib/libX11.so.6.2.0 I can see offsets starting from 0xA3517 to 0x135C0 (i.e. only 0x8FF57). Is there any reason for that?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
/proc/X/maps 中 rx 部分的首地址（也可以使用“pmap X”）是库的第一个虚拟地址，而 objdump --disassemble 显示的偏移量是假设开始的虚拟地址0。您感兴趣的地址是 0xE53E8（假设您给出的数字来自查看 rx 映射），因此在 objdump --disassemble 输出中查找该地址以找到正确的代码位置。
请注意，您可以使用 gdb 直接查看正在运行的程序的内存。启动 gdb，然后运行“attach X”，其中 X 是正在运行的程序的 PID，然后“反汇编 0xB71B13E8”。
The first address of the r-x section in /proc/X/maps (you can use 'pmap X', too) is the first virtual address of the library, while the offsets displayed by objdump --disassemble are the virtual addresses assuming a start of 0. The address you're interested in is 0xE53E8 (assuming the numbers you gave are from looking at the r-x mapping), so look for that address in the objdump --disassemble output to find the correct code location.
Note that you can use gdb to directly look at a running program's memory. Start gdb then run 'attach X' where X is the PID of the running program, then 'disassemble 0xB71B13E8'.