gcc 的 -pg 标志如何工作? [英] How does gcc's -pg flag work?

问题描述

我试图了解在使用 gcc 编译 C 代码时 -pg(或 -p)标志是如何工作的.

官方 gcc 文档仅说明:

<块引用>

-pg
生成额外的代码来编写适合分析程序 gprof 的配置文件信息.编译需要数据的源文件时必须使用此选项，链接时也必须使用它.

这真的让我很感兴趣，因为我正在做一个关于分析器的小型研究 - 试图为这项工作挑选最好的工具.

解决方案

使用 -pg 编译您的代码，以便 gprof 报告详细信息，请参阅 gprof 的手册，9.1 分析的实现

<块引用>

分析的工作原理是改变程序中每个函数的编译方式，以便在调用它时，它会隐藏一些有关从何处调用它的信息.由此，分析器可以找出调用它的函数，并可以计算它被调用的次数.当您的程序使用 -pg 选项编译时，编译器会进行此更改，这会导致每个函数调用 mcount(或 _mcount，或 __mcount，取决于操作系统和编译器)作为它的第一个操作.

mcount 例程包含在分析库中，负责在内存调用图表中记录其父例程(子)及其父例程.这通常是通过检查堆栈帧以查找子进程的地址和原始父进程中的返回地址来完成的.由于这是一个非常依赖机器的操作，mcount 本身通常是一个简短的汇编语言存根例程，它提取所需的信息，然后调用 __mcount_internal(一个普通的 C 函数) 带有两个参数——frompc 和 selfpc.__mcount_internal 负责维护内存调用图，其中记录了frompc、selfpc，以及每个调用弧被调用的次数穿过.

...

请注意，使用这样的检测分析器，您分析的代码与在发布时编译的代码相同，而无需分析检测.存在与检测代码本身相关的开销.此外，检测代码可能会改变指令和数据缓存的使用.

与检测分析器相反，采样分析器如 IntelVTune 通过使用操作系统中断定期查看目标程序的程序计数器来处理非检测代码.它还可以查询特殊的 CPU 寄存器，让您更深入地了解正在发生的事情.

另见分析器检测与采样

I'm trying to understand how the -pg (or -p) flag works when compiling C code with gcc.

The official gcc documentation only states:

-pg
Generate extra code to write profile information suitable for the analysis program gprof. You must use this option when compiling the source files you want data about, and you must also use it when linking.

This really interests me, as I'm doing a small research on profilers - trying to pick the best tool for the job.

解决方案

Compiling with -pg instruments your code so that gprof reports detailed information, see gprof's manual, 9.1 Implementation of Profiling

Profiling works by changing how every function in your program is compiled so that when it is called, it will stash away some information about where it was called from. From this, the profiler can figure out what function called it, and can count how many times it was called. This change is made by the compiler when your program is compiled with the -pg option, which causes every function to call mcount (or _mcount, or __mcount, depending on the OS and compiler) as one of its first operations.

The mcount routine, included in the profiling library, is responsible for recording in an in-memory call graph table both its parent routine (the child) and its parent's parent. This is typically done by examining the stack frame to find both the address of the child, and the return address in the original parent. Since this is a very machine-dependent operation, mcount itself is typically a short assembly-language stub routine that extracts the required information, and then calls __mcount_internal (a normal C function) with two arguments—frompc and selfpc. __mcount_internal is responsible for maintaining the in-memory call graph, which records frompc, selfpc, and the number of times each of these call arcs was traversed.

...

Please note that with such an instrumenting profiler, you're profiling the same code you would compile in release without profiling instrumentation. There is an overhead associated with the instrumentation code itself. Also, the instrumentation code may alter instruction and data cache usage.

Contrary to an instrumenting profiler, a sampling profiler like Intel VTune works on non instrumented code by looking at the target program's program counter at regular intervals using operating system interrupts. It can also query special CPU registers to give you even more insight of what's going on.

See also Profilers Instrumenting Vs Sampling

这篇关于gcc 的 -pg 标志如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！