GCC能打印出中间结果吗？

检查下面的代码：

#include <avr/io.h> const uint16_t baudrate = 9600; void setupUART( void ) { uint16_t ubrr = ( ( F_CPU / ( 16 * (float) baudrate ) ) - 1 + .5 ); UBRRH = ubrr >> 8; UBRRL = ubrr & 0xff; } int main( void ) { setupUART(); }

这是用于编译代码的命令：

avr-gcc -g -DF_CPU=4000000 -Wall -Os -Werror -Wextra -mmcu=attiny2313 -Wa,-ahlmns=project.lst -c -o project.o project.cpp

ubrr由编译器计算为25，到目前为止这么好。 但是，为了检查编译器的计算结果，我已经查看了反汇编列表。

000000ae <setupUART()>: ae: 12 b8 out UBRRH,r1 ; 0x02 b0: 89 e1 ldi r24,0x19 ; 25 b2: 89 b9 out UBRRL,r24 ; 0x09 b4: 08 95 ret

是否有可能让avr-gcc 在编译时打印出中间结果（或从.o文件中取出信息），所以当我编译代码时，它会打印出一个如(uint16_t) ubbr = 25或类似的行？ 这样我可以做一个快速的健全性检查计算和设置。

ATTiny和Linux AVR-GCC中断复位向量在链接器中

GCC有命令行选项来请求它在任何编译阶段后转储出它的中间表示。 “树”转储采用伪C语法，并包含所需的信息。 对于你想要做的事情，在优化管道中有用的点上会发生-fdump-tree-original和-fdump-tree-optimized转储。 我没有一个AVR编译器，所以我修改了你的测试用例，使其能够自我编译，并且可以编译我所拥有的编译器：

typedef unsigned short uint16_t; const int F_CPU = 4000000; const uint16_t baudrate = 9600; extern uint16_t UBRRH,UBRRL; void setupUART(void) { uint16_t ubrr = ((F_CPU / (16 * (float) baudrate)) - 1 + .5); UBRRH = ubrr >> 8; UBRRL = ubrr & 0xff; }

接着

$ gcc -O2 -S -fdump-tree-original -fdump-tree-optimized test.c $ cat test.c.003t.original ;; Function setupUART (null) ;; enabled by -tree-original { uint16_t ubrr = 25; uint16_t ubrr = 25; UBRRH = (uint16_t) ((short unsigned int) ubrr >> 8); UBRRL = ubrr & 255; } $ cat test.c.149t.optimized ;; Function setupUART (setupUART,funcdef_no=0,decl_uid=1728,cgraph_uid=0) setupUART () { <bb 2>: UBRRH = 0; UBRRL = 25; return; }

你可以看到，常量表达式折叠很早就发生了，它已经发生在“原始”转储（这是你可以拥有的最早的可理解的转储），并且优化进一步将转换和掩码操作折叠成了写入UBRRH和UBRRL。

文件名（003t和149t）中的数字可能会有所不同。 如果要查看所有 “树”转储，请使用-fdump-tree-all 。 还有“RTL”转储，看起来不像C，可能对你没用。 如果你很好奇，但是， -fdump-rtl-all将会打开它们。 总共有大约100个树和60个RTL转储，因此在暂存目录中执行此操作是一个好主意。

（Psssst：每当你在括号里面放上空格时，上帝就会杀死一只小猫。）

打印中间结果可能有一个解决方案，但需要一些时间才能实施。 所以只有一个相当大的源代码库是值得的。

你可以定制你的GCC编译器; 通过一个插件（痛苦地用C或C ++编码）或者通过MELT扩展。 MELT是一个高级的，Lisp式的，特定于领域的语言来扩展GCC。 （它被实现为GCC的[meta]插件并被转换为适合GCC的C ++代码）。

然而，这种方法要求您了解GCC内部，然后添加您自己的“优化”通行证来执行面向方面的编程 （例如使用MELT）来打印相关的中间结果。

你也可以看看生成的程序集（也可以使用-fverbose-asm -S作为GCC的选项），也可以在生成的-fdump-tree-gimple表示中（可能使用-fdump-tree-gimple ）。 对于某些交互式工具，请考虑图形化的MELT探针 。

也许增加你自己的内建（使用MELT扩展）像__builtin_display_compile_time_constant可能是相关的。

我怀疑有一个简单的方法来确定编译器的功能。 gcc中可能会有一些工具专门用于转储语言的中间形式，但绝对不容易阅读，除非您真的怀疑编译器做错了什么（并且有一个非常小的例子来显示它） ，不太可能将它用于任何有意义的事情 – 仅仅是因为太多的工作来跟踪正在发生的事情。

一个更好的方法是添加临时变量（也许是打印）到你的代码，如果你担心它是正确的：

uint16_t ubrr = ( ( F_CPU / ( 16 * (float) baudrate ) ) - 1 + .5 ); uint8_t ubrr_high = ubrr >> 8 uint8_t ubrr_low = ubrr & 0xff; UBRRH = ubrr_high; UBRRL = ubrr_low;

现在，如果你有一个非优化的构建，并在GDB中逐步完成，你应该能够看到它的功能。 否则，在代码中添加某种打印输出以显示值…

如果你不能在目标系统上打印它，因为你正在设置将用于打印的uart，然后在本地主机系统上复制代码并在那里进行调试。 除非编译器非常麻烦，否则应该从相同的编译中获得相同的值。

这里有一个黑客：现在只需要手动自动化你正在做的事情。

在你的makefile中，确保avr-gcc产生一个反汇编（ -ahlms= output.lst ）。 或者，使用自己的反汇编方法作为makefile中的后编译步骤。

作为后编译步骤，使用您最喜欢的脚本语言处理您的列表文件，以查找out UBRRL和out UBRRL行。 这些将从寄存器中加载，所以你的脚本可以将之前的分配分配到将被加载到UBRRH和UBRRL寄存器中。 然后，脚本可以从加载到通用寄存器的值中重新组合UBRR值，通用寄存器用于设置UBRRH和UBRRL 。

这听起来比Basile Starynkevich对MELT扩展的非常有用的建议更容易。 现在，如果认为这个解决方案看起来很脆弱，我们首先应该考虑这个问题：

我们知道 （至少在你的处理器上） out UBRR_,r__会出现在反汇编列表中：除此之外，没有其他方法可以设置寄存器/写数据到端口。 有一件事情可能会改变，就是这些行之间的间隔，但这可以通过脚本轻松处理

我们也知道，只能从通用寄存器中out指令，所以我们知道通用寄存器是指令行的第二个参数，所以不应该是一个问题。

最后，我们也知道这个寄存器将在out指令之前被设置。 这里我们必须考虑到一些可变性：而不是LDI （立即加载），avr-gcc可能会产生一些其他指令来设置寄存器值。 我认为作为第一次通过，脚本应该能够解析立即加载，否则转储它发现涉及将被写入UBRR_端口的寄存器的最后指令。

如果你改变了平台，脚本可能不得不改变（一些处理器有UBRRH1 / 2寄存器UBRRH ，但是在这种情况下，你的波特代码将不得不改变，如果脚本指出它不能解析反汇编，至少知道你的支票没有被执行。