哪个变量存储 gcc 中 C GENERIC AST 的根节点?
我正在尝试为 gcc 4.5 编写一个插件,它将对 AST 执行一些分析( GENERIC 表示)在解析完成后。我的源语言是 C,插件也将用 C 编写。有一些帖子 这里解释了如何为 C++ 做这样的事情。 GENERIC 文档和之前的链接都声明变量 global_namespace
存储 C++ GENERIC AST 的根节点。哪个变量存储 C GENERIC AST 的根节点?
提前致谢!
I am trying to write a plugin for gcc 4.5 that will perform some analysis on the AST (GENERIC representation) just after parsing is complete. My source language is C and the plugin will be written in C as well. There are a few posts here that explain how to do such a thing for C++. Both the GENERIC documentation and the previous link state that the variable global_namespace
stores the root node of a C++ GENERIC AST. Which variable stores the root node of a C GENERIC AST?
Thanks in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
C 显然不存在命名空间之类的东西,但是范围的概念确实存在。您可以通过
c-tree.h
中定义的函数pop_scope()
访问您所在位置的 englobing 范围(这取决于 GCC 调用您的插件的事件) 。这将返回一个由块
组成的树
。您可以通过宏BLOCK_VARS
访问该块的所有声明,即在此范围内声明的符号(变量、函数等),该宏为您提供了一个树
decl 节点。如果您需要访问函数体,请记住,您始终可以通过宏
DECL_SAVED_TREE(node)
从函数定义中访问它,node
是您的FUNCTION_DECL< /代码> 节点。仅当定义位于同一文件中并且已经构建时,这才有效,同样,这取决于您挂钩插件的位置。
免责声明:这对 GCC 4.8 有效,并且界面可能会经常更改。从 GCC 4.9 开始,插件接口部分用 C++ 编写。
There are obviously no such things as namespaces for C but the concept of scopes does exist however. You can access the englobing scope of where you are (that depends on which event your plugin is called by GCC) through the function
pop_scope()
defined inc-tree.h
. This returns atree
which is composed of ablock
. You can access all the declarations of this block, i.e. the symbols (variables, functions, etc.) declared at this scope through the macroBLOCK_VARS
which provides you with atree
of decl-nodes.If you neeed access to a function body, remember than you can always access it from the function definition through the macro
DECL_SAVED_TREE(node)
,node
being yourFUNCTION_DECL
node. This is valid only if the definition is in the same file and already built, again, it depends on where you hook your plugin.Disclaimer: this is valid for GCC 4.8 and the interface is subject to frequent changes. As of GCC 4.9, the plugin interface is partially written in C++.