使用 PTRACE_SINGLESTEP 计算进程的机器指令数
在 Linux 机器上，我使用带有 PTRACE_SINGLESTEP 参数的 ptrace 来计算程序的机器指令数。我关注了这篇文章： http://www.ncsu .edu/it/mirror/ldp/LDP/LGNET/81/sandeep.html。
然而，结果对我来说似乎很奇怪。对于一个非常简单的程序，计算出超过 95000 条机器指令。测试程序是
int main(void) { return 23; }
What's goon Here？文章中的代码有错吗？ （我看不出有什么问题。） 如果不是，那么是什么原因导致如此简单的程序需要超过 95000 条指令？
on a Linux machine, I am using ptrace with the PTRACE_SINGLESTEP parameter to count the number of machine instructions of a program. I followed this article: http://www.ncsu.edu/it/mirror/ldp/LDP/LGNET/81/sandeep.html.
However, the result seems odd to me. For a very simple program, over 95000 machine instructions are counted. The test program is
int main(void) { return 23; }
What's going on here? Is the code from the article wrong? (I can't see what's wrong with it.)
If not, what causes such a simple program to require >95000 instructions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您正在编译的 C 程序链接到 C 库。它包含程序执行开始的
_start符号。此时，C 库会初始化自身并最终调用main。在main返回后，控制流回_start，并且还有一堆其他指令要执行并返回程序返回值。请注意，连续使用PTRACE_SINGLESTEP不会计算已编译指令的数量。它计算执行的指令的数量。这意味着在进入main之前、执行main时以及退出main后会执行 95k 条指令。The C program you're compiling is linked to C library. It contains the
_startsymbol which the program execution starts from. At that point, C library initializes itself and eventually callsmain. Aftermainreturns, the control flows back to_startand there are a bunch of other instructions to execute and return the program return value. Note that usingPTRACE_SINGLESTEPsuccessively doesn't count the number of compiled instructions. It counts the number of executed instructions. That means 95k instructions are executed before enteringmain, when executingmainand after exitingmain.这是由于所谓的“软件膨胀”造成的。您必须初始化和完成 stdio，甚至可能需要一些渗入标准 C 运行时的线程代码。如果您进一步阅读并分析它，您可能会确切地知道是什么。或者你可以直接阅读源码。
更新：实际上，我后来意识到你可能一直在跟踪动态链接器的操作，这有很多工作要做。我看到有人留下了这样的评论，所以我投票了。如果您没有静态链接程序，那么我们最初的答案基本上都是错误的。
It's due to something called "software bloat". You have to initialize and finalize stdio, and maybe even some threading code that bled into the standard C runtime. If you read a little further and profile it you may find out exactly what. Or you could just read the source.
Update: Actually, I realized later that you have probably been tracing through the operation of the dynamic linker, which has a lot of work to do. I see that someone left such a comment, so I upvoted the comment. If you didn't link the program statically, then both of our original answers were basically wrong.