“–print-memory-usage” 在 GCC 中的工作原理是什么?

huangapple go评论106阅读模式
英文:

working of “–print-memory-usage” in the GCC?

问题

GCC如何使用--print-memory-usage选项提供链接器文件中定义的每个内存区域使用的内存的详细信息?

英文:

how does GCC provide a breakdown of the memory used in each memory region defined in the linker file using --print-memory-usage?

答案1

得分: 2

GCC只是将--print-memory-usage传递给链接器,通常是ld

https://sourceware.org/binutils/docs-2.40/ld.html#index-memory-usage

gcc(或者g++)对内存使用情况一无所知,而链接器只能报告静态存储内存的使用情况,通常包括:

.text:要执行的“程序”或代码。这可能位于RAM或ROM(例如Flash),具体取决于选项和架构。

.rodata:静态存储中的只读数据,不需要在运行时初始化。通常位于ROM或Flash等非易失性存储器中,但也有例外情况,其中之一是avr-gcc

.data、**.bss**和COMMON:RAM中在启动时由CRT(C运行时)初始化的数据。

除了这些常见的部分,还可能存在其他部分,例如.init*.boot.jumptables等,这再次取决于应用程序和架构。

由于其性质,链接器(或汇编器或编译器)无法确定运行时展开的内存使用情况,包括:

  • 堆栈使用:无法保存在寄存器中的非静态局部变量,alloca等。

  • 堆使用mallocnew等。

编译器可以为您做的是-fstack-usage等选项,它会为每个翻译单元生成一个文本文件*.su。编译器报告在编译时已知的静态堆栈使用和在运行时出现的未知堆栈使用(动态)。标记为static的函数使用指定数量的堆栈空间,而不计算非内联调用者的使用情况。

要了解完整的堆栈使用情况(或可靠的上限),必须了解动态调用图。即使已知,GCC也不会为您执行分析。您需要其他更复杂的工具来计算这些指标,例如抽象解释或其他静态分析手段。

请注意,像运行时收集的数据,例如运行时动态堆栈使用分析,只提供内存使用(或执行时间)的下限。但是,对于像安全关键应用中的可靠分析,您需要的是上限

英文:

GCC just forwards --print-memory-usage to the linker, usually ld:

https://sourceware.org/binutils/docs-2.40/ld.html#index-memory-usage

gcc (or g++ for that matter) has no idea about memory usage, and the linker can only report usage of static storage memory, which is usually:

.text: The "program" or code to be executed. This might be located in RAM or in ROM (e.g. Flash) depending on options and architecture.

.rodata: Data in static storage that is read-only and does not need initialization at run-time. This is usually located in non-volatile memory like ROM or Flash; but there are exceptions, one of which is avr-gcc.

.data, .bss and COMMON: Data in RAM that's initialized during start-up by the CRT (C Runtime).

Apart from these common setcions, there might be other sections like .init*, .boot, .jumptables etc, which again depend on the application and architecture.


By its very nature, the linker (or assembler or compiler) cannot determine memory usage that unfolds at run-time, which is:

  • Stack usage: Non-static local variables that cannot be held in registers, alloca, ...

  • Heap usage: malloc, new and friends.

What the compiler can do for you is -fstack-usage and similar, which generates a text file *.su for each translation unit. The compiler reports stack usage that's known at compile time (static) and unknown stack usage that arises at run-time (dynamic). The functions marked as static use the specified amount of stack space, without counting the usages of non-inlined callees.

In order to know the complete stack usage (or a reliable upper bound), the dynamic call graph must be known. Even if it's known, GCC won't do the analysis four you. You will need other more elaborate tools to work out these metrics, e.g. by abstract interpretation or other means of static analysis.

Notice that data collected at run-time, like dynamic stack usage analysis at run time, only provide a lower bound of memory usage (or execution time for that matter). However, for sound analysis like in safety-scitical apps, what you meed are upper bounds.

huangapple
  • 本文由 发表于 2023年2月6日 18:05:18
  • 转载请务必保留本文链接:https://go.coder-hub.com/75359853.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定