花开的地方花开，没有声音……

根据Linux内核文档介绍:

这是一组’魔术组合键’，只要内核没有被完全锁住，不管内核在做什么事情，使用这些组合键可以立即打印出内核的信息。
使用sysrq组合键是了解系统目前运行情况的最好方式。如果系统出现挂起的情况或者在诊断一些和内核相关，比较怪异，比较难重现的问题的时候，使用sysrq键是一个比较好的方式。
如何打开和关闭SysRq组合键?
为了安全起见，在红帽企业版Linux里面，默认SysRq组合键是关闭的。 打开这个功能，运行:
# echo 1 > /proc/sys/kernel/sysrq

关闭这个功能:
# echo 0 > /proc/sys/kernel/sysrq

如果想让此功能一直生效，在/etc/sysctl.conf里面设置kernel.sysrq的值为1. 重新启动以后，此功能将会自动打开。

kernel.sysrq = 1

因为打开sysrq键的功能以后，有终端访问权限的用户将会拥有一些特殊的功能。因此，除非是要调试，解决问题，一般情况下，不要打开此功能。如果一定要打开，请确保您的终端访问的安全性。

如何触发一个sysrq事件?

有几种方式可以触发sysrq事件。在带有AT键盘的一般系统上，在终端上输入一下组合键:

Alt+PrintScreen+[CommandKey]

例如，要让内核导出内存信息(CommandKey “m”)，您应该同时按下Alt 和 Print Screen 键，然后按下 m 键. 提示: 此组合键在Xwindows上是无法使用的。所以，您先要切换到文本虚拟终端下。如果您现在是在图形界面，可以按Ctrl+Alt+F1切换到虚拟终端。

在串口终端上,要想获得同样的效果，需要先在终端上发送Break信号，然后在5秒内输入sysrq组合键。

如果您在机器上有root权限，您可以把commandkey字符写入到/proc/sysrq-trigger文件。这可以帮助您通过脚本或者您不在系统终端上的时候触发sysrq事件。

# echo ‘m’> /proc/sysrq-trigger

当我触发一个sysrq事件的时候，接过保存在什么地方?

当一个sysrq命令被触发，内核将会打印信息到内核的环形缓冲并输出到系统控制台。此信息一般也会通过syslog输出到/var/log/messages.

有时候，可能系统已经无法响应，syslogd可能无法记录此信息。在这种情况下，建议您配置一个串口终端来收集这个信息。

那些类型的sysrq事件可以被触发?

sysrq功能被打开后，有几种sysrq事件可以被触发。不同的内核版本可能会有些不同。但有一些是共用的:

* m – 导出关于内存分配的信息

* t – 导出线程状态信息

* p – 到处当前CPU寄存器信息和标志位的信息

* c – 故意让系统崩溃(在使用netdump或者diskdump的时候有用)

* s – 立即同步所有挂载的文件系统

* u – 立即重新挂载所有的文件系统为只读

* b – 立即重新启动系统

* o – 立即关机(如果机器配置并支持此项功能)

刚发现了一个不错的DNS检查站点：http://www.checkdns.net/
可以检查你的DNS是否工作的正常（是否配置、架构有误）。

另一个不错的工具网站：http://www.robtex.com/  一个查IP，查域名，查网络机构的工具，相当不错。

　　计算机可不仅仅是放在我们桌子上或者大腿上的样子；我们天天讨论的各种硬件，甚至是发烧级的硬件在某些时候看来仅仅就是不入流的小儿科。普通的计算机就已经让我们的生活发生了很大的变化，其实在我们生活的背后还有一些更为强大的超级计算机，默默的让我们的生活发生着更为巨大的变化。
　　在这里先跟大家解释一个名词：Teraflop，万亿次浮点计算。在超级计算领域，浮点计算(flop)是一个缩写，其完整的含意为“每秒浮点计算次数”(FLoating point Operations Per Second)，是一种计算机执行浮点计算能力的衡量标准。万亿次计算即为每秒一万亿次浮点计算。
　　7. Tera-10——法国原子能署
　　Bull SA为法国原子能署建造的这台Tera-10，在世界上最快的500台计算机排行榜中名列第七。Tera-10由544台Bull的NovaScale 6160服务器组成，每一台这样的服务器都配有8颗双核Intel安腾（Itanium）处理器，运行速度大约是42.9万亿次浮点计算。这台超级计算机使用Linux操作系统，用来模拟原子能试验。

(Tera-10)

(Tera-10)
(Tera-10)
(Tera-10) 　　6. Thunderbird——美国圣地亚国家实验室 　　Dell公司开发的Thunderbird是一台拥有8960颗处理器的Linux集群服务器，目前放置在美国新墨西哥州阿布奎基的圣地亚国家实验室，这一个国家级的原子能安全管理实验室。这一部集群服务器执行多个中型任务的表现要比执行单一大型任务出色的多。
　　Thunderbird达到53.0万亿次浮点计算的速度，使得它在世界上最快的500台计算机排行榜中名列第六。目前这台超级计算机主要用来模拟武器的性能、半导体设备的辐射状况、极端环境下的武器安全性能等等工作。

(Thunderbird) 　　5. MareNostrum——巴塞罗那超级计算中心 　　MareNostrum是目前欧洲最强大的超级计算机，它拥有10240颗处理器，峰值计算速度能够达到94.21万亿次浮点计算。组成MareNostrum的2560台JS21刀片式计算结点占据了大约半个篮球场（120平米）的面积，现在位于西班牙的巴塞罗那超级计算中心。
　　MareNostrum目前的应用相当广泛，包含人类基因的研究、天气预报、药品研究等等领域。

(MareNostrum)
(MareNostrum)
(MareNostrum)
(MareNostrum)
(MareNostrum)
(MareNostrum) 　　4. ASC Purple——美国劳伦斯利弗莫尔国家实验室
　　ASC Purple是美国劳伦斯利弗莫尔国家实验室和IBM通力合作的结晶。其峰值100万亿次浮点计算的能力，来源于196台IBM Power5 SMP服务器冗余环的强大性能。实际上这台超级计算机总共拥有12544颗微处理器，50TB的内存和2PB的磁盘存储空间。
　ASC Purple目前被用来模拟测试核武器的性能，而过去常常需要通过底下核试验才能测得。

(ASC Purple)
(ASC Purple)
(ASC Purple) 　3. BGW (Blue Gene/W)——IBM华生研究中心　　在IBM的华生研究中心，可以找到这部叫做Blue Gene/W或BGW的超级计算机，其峰值的运行速度可以达到114万亿次浮点计算。组成Blue Gene/W的是20台冰柜那样的架子组成，每一个架子里面包含1024个节点，每一个节点拥有两个700MHz的Power 440处理器和512MB的内存。
　　Blue Gene/W的主要工作是进行科学计算，例如生物学模拟、蛋白质折叠和其他IBM科学家的研究工作。

(BGW)
(BGW)
(BGW) 　2. Red Storm——美国圣地亚国家实验室 　　Red Storm是Cray公司和圣地亚国家实验室联合设计的并行处理超级计算机，其主要应用是模拟测试核武器的储备情况，包括设计替换的成分、模拟测试在不同环境下各个部分的情况、帮助武器工程师和科学家进行辅助计算等等。
　　Red Storm由12960台配备AMD皓龙（Opteron）处理器的节点组成，峰值运算速度能够达到124.42万亿次浮点计算。这台超级计算机仅仅使用了一套小型的Linux操作系统，只具有一些能够支持Red Storm应用的功能。

(Red Storm)
(Red Storm)
(Red Storm)
(Red Storm) 　1. Blue Gene/L——美国劳伦斯利弗莫尔国家实验室　　Blue Gene/L是目前世界常最快的超级计算机，其峰值速度能够达到360万亿次浮点计算。这台超级计算机内部拥有65536颗处理器，同样运行着Linux操作系统。这是IBM公司、利弗莫尔实验室和美国能源部联合制作完成的超级计算机，由于采用了基于单元的设计结构，使之能够随时添加计算单元而不需要担心遭遇瓶颈的问题。
　　最近，Blue Gene/L因为执行一项与半个老鼠大脑一样复杂的脑皮层模拟而被进一步关注，半个老鼠大脑拥有800万神经元细胞，每一个细胞与其他神经纤维之间有8000个链接。除此之外，Blue Gene/L通常用来模拟包括蛋白质在内的生物化学过程。
(Blue Gene/L)
(Blue Gene/L)
(Blue Gene/L)
(Blue Gene/L)

　　相信“arp欺骗”让不少管理员疲于奔命。下面讲一个自己偶然得到启示得到的一个方法——其实最重要的启示是如何让Windows上的arp绑定操作开机自动运行。
　　直接进入主题，在底层禁止arp通信是解决arp欺骗的根本方法。为了不使设备对某个地址进尽arp广播查询，需要将ip->mac这个对应关系的记录以“静态”的属性写进“arp table”里。在Windows/Linux系统里，可以使用以下命令进行静态arp table记录的添加：
　　arp -s 网关ip地址　网关mac地址

　　应该有不少系统管理员已经知道通过绑定静太MAC地址，可以防止arp欺骗，但是这种绑定必须是双方的，需要进行二层通信的双方都进行mac绑定，一般为：在服务器上绑定网关的ip->mac为静态，在网关上绑定服务器的ip->mac为静态。通过绑定网关地址的mac为静态，只可以保证从服务器到网关（路由器）之间不会被欺骗、被插入，从网关（路由器）到服务器仍然是可以被插入或者被欺骗的，要做到in和out两路都受到保护，就需要在网关上同样地绑定服务器的mac地址为静态（这个对于大多数服务器的ISP来说，可能都不愿意做——因为合同上并没有要求要做这些，多一事不如少一事，更有管理员认为做这些配置会增加路由器的负载——貌似没有什么根据）。

　　现在的问题是，第一，如何让ISP给我们的服务器ip地址的mac绑定成静态，貌似有点难度，在管理不是很严格的机房，跟管理人员搞好关系应该就可以做到。或者直接找业务部门，要求他们提供这样的服务。第二，对于Windows系统，每次重启系统都要手动绑定一次，真的很不方便。有人把这些操作写成批处理加到autorun.bat里，但是似乎起不了作用。加到“开始/程序/启动”里，貌似也不行，这些都是需要管理员登录进系统才能运行的，况且将arp登录写入批处理，不知道为什么总是返回不了。我的做法是，把这个绑定操作设置成计划任务，设备成开机运行。计划任务是做为后台服务在运行的，所以用户不登录系统，这个操作依然可以完成。这个操作已经经过测试，可以正常运行：大致上，任务的命令行为：C:\windows\system32\arp.exe -s 网关ip地址　网关mac

引用：

　　讨论与Blog相关的技术，不可不谈的就是RSS，这个缩写在英文中可以有几个源头，并被不同的技术团体做不同的解释。既可以是“Rich Site Summary”，或“RDF Site Summary”，也可以是“Really Simple Syndication”。为什么有这么多含义呢？这还要从RSS的一段今天也没有理清的关系说起。
　　今天肯定有人还记得IE 4刚刚推出来的时候有一个有趣的功能，那就是新闻频道。这个新闻频道的功能与Netscape推出的新闻频道是很相似的(当时Netscape还是市场上领先的浏览器)。为此Netscape 定义了一套描述新闻频道的语言，这就是RSS，只不过Netscape自当时起每况愈下，所以最终也没有发布一个正式的RSS规范(只发布了一个0.9版本)。而微软也在当时推出了支持自己IE的CDF(Channel Definition Format)数据规格，与RSS非常接近。微软试图用新闻频道的功能把“推”(Push)技术变成一个应用主流，并与Netscape抗衡。不过出乎预测的是，“推”技术自始至终没有找到合适的商业模型，而且伴随着其他各类网络特性的出现，也日益无法显现自身的优势。新闻频道在浏览器中的地位最终日暮西山，最后也在IE的后续版本中消失了。
　　新闻频道的确进入了低谷，但是RSS并没有被业界人士所抛弃。过去两年，Blog从一个专业群体开始，逐步成为了网络上最热门的新话题。而RSS成为了描述Blog主题和更新信息的最基本方法。于是RSS这项技术被著名Blogger/Geek戴夫·温那(Dave Winner)的公司UserLand所接手，继续开发新的版本，以适应新的网络应用需要。新的网络应用就是Blog，因为戴夫·温那的努力，RSS升级到了0.91版，然后达到了0.92版，随后在各种Blog工具中得到了应用，并被众多的专业新闻站点所支持。在广泛的应用过程中，众多的专业人士认识到需要组织起来，把RSS发展成为一个通用的规范，并进一步标准化。一个联合小组根据W3C新一代的语义网技术RDF对RSS进行了重新定义，发布了RSS 1.0，并把RSS定义为“RDF Site Summary”。这项工作并没有与戴夫·温那进行有效的沟通，而戴夫则坚持在自己设想的方向上进一步开发RSS的后续版本，也并不承认RSS 1.0的有效性。RSS由此开始分化形成了RSS 0.9x/2.0和RSS 1.0两个阵营，也由此引起了在专业人群中的广泛争论。
　　因为争论的存在，一直到今天，RSS 1.0还没有成为标准化组织的真正标准。而戴夫·温那却在2002年9月独自把RSS升级到了2.0版本，其中的定义完全是全新的模式，并没有任何RSS 1.0的影子。这引发了网络上进一步争议，究竟让一个越来越普及的数据格式成为一个开放的标准，还是被一家公司所定义和控制，成为了争议的焦点。戴夫·温那并没有为自己辩解，他的观点是RSS还需要进一步发展，需要专业人士更明确的定义，不过恐怕这种轻描淡写不能消除人们对RSS“被一家商业公司独占”的担心。
　　前面的铺垫对用户来说也许没有什么太大的意义，可能更多人关心如何在自己的Blog增加RSS输出，这样可以让很多新闻聚合工具(例如CNBlog刚刚推荐的NewzCrawler)很容易找到你并自动获得你在Blog中的更新内容。
　　它是什么：站点用来和其他站点之间共享内容的简易方式(也叫聚合内容)。 RSS使肵ML作为彼此共享内容的标准方式。
　　它代表什么：Really Simple Syndication (或RDF Site Summary，RDF站点摘要)
　　例如：一些免费的软件能够让你阅读那些RSS使能的站点，比如 NewsIsFree 和 Amphetadesk。
　　它有什么用处：让别人容易的发现你已经更新了你的站点，让人们很容易的追踪他们阅读的所有weblogs。
　　原文出处：博客中国

GNU 编译器家族 GCC 内部探密 探索 GCC 前端的内部结构
 
 
 
探索 GCC 前端的内部结构

赵蔚 (zhaoway@public1.ptt.js.cn)

Linux 和自由软件技术独立顾问

2003 年 7 月

我们在本文中说明 GCC 源码包中的例子编程语言 Treelang 的实现细节。主要目的在于辑此说明所谓 GCC 前端的编程方法。限于篇幅，本文只能略略讲一下 GCC 前端的内部结构的框架部分。本文中所涉及到的源程序均位于 GCC 源码包中的 gcc/ 目录和 gcc/treelang/ 目录下。本文的代码分析基于 GCC CVS 中的最新（2003 年六月）的开发版本。
GNU 编译器家族 GCC 介绍

作为自由软件的旗舰项目，Richard Stallman 在十多年前刚开始写作 GCC 的时候，还只是把它当作仅仅一个 C 程序语言的编译器；GCC 的意思也只是 GNU C Compiler 而已。经过了这么多年的发展，GCC 已经不仅仅能支持 C 语言；它现在还支持 Ada 语言，C++ 语言，Java 语言，Objective C 语言，Pascal 语言，COBOL 语言，以及支持函数式编程和逻辑编程的 Mercury 语言，等等。而 GCC 也不再单只是 GNU C 语言编译器的意思了，而是变成了 GNU Compiler Collection 也即是 GNU 编译器家族的意思了。

另一方面，说到 GCC 对于各种硬件平台的支持，概括起来就是一句话：无所不在。几乎所有有点实际用途的硬件平台，甚至包括有些不那么有实际用途的硬件平台，比如 Don Knuth 设计的 MMIX 计算机，GCC 都提供了完善的支持。

我们在这篇文章中要弄清楚的就是 GCC 是如何做到能够支持这么多种程序语言的。所谓的 GCC 的程序语言前端到底是怎么回事。如果我们要设计实现自己的编程语言的话，应该从何入手。回答这些问题的第一步，就是分析清楚 GCC 源码包中，为了说明 GCC 的程序语言前端的编写方法，而写作的 Treelang 编程语言在 GCC 中的实现细节。

如果把我们自己的程序语言的实现建立于 GCC 之上，也立刻使得我们的程序语言的实现版本可以运行在几乎所有有用的硬件平台之上。这对于程序语言的作者来说，也是一个确实的有极大诱惑力的好处。

关于代码分析

在这一小节里面我们着重说明两个问题：第一、为什么要阅读源代码；第二、代码分析应该怎么写。

阅读源代码对提高自己的编程水平是非常有帮助的。这个帮助至少体现在两个方面。第一个方面是学会大型软件项目设计的模式。这样的模式是真实可靠的第一手资料，这样学来的模式要比从书本上，用日常语言陈述的模式，更能深入到你的脑海中去。而且它的真实性和可靠性都是有保证的。并且这样的模式还非常的具体。我曾经看到计算机系的同学推荐去读亚历山大的建筑学方面的经典著作；个人以为这是走的太远了。与其去读建筑学的书，不如去分析一下成功的自由软件项目的源代码。具体的用代码说明的模式，无论如何要比虚无飘渺的美学概念，或者模棱两可的工程纪律，都要更加容易学习吧？

阅读源代码的第二个好处，是增加自己的自信心。就象学习英语，要和别人谈话，要看看别人的文章，不能只是看教科书上的简单的例子。教科书上的例子限于篇幅，不可能做到像真实、完整的英文小说那样，把一个完整的设计呈现在你的面前。只有当你硬着头皮，抛开字典，把一本英文小说生生啃下来之后，你才能有把握说：我的确能做到。类似的，只有当我们看过大型软件项目的源代码，作过修改，摸爬滚打之后，我们才能有把握的说：我也能写出来。

上面说了阅读源代码至少有这么两个好处。那么在阅读源代码的时候，我们必然要做代码分析笔记。这个代码分析笔记如何写，这就是我们关心的一个问题了。在这里，我提出一些我自己的也许不太成熟的看法，也请读者朋友们不吝指教。

我总觉得，与其作一行一行的代码注释，说明每一行代码的作用；不如设计一个故事，把代码的框架说清楚。这也是我前面提到的，所谓模式一说。因为阅读源代码，最关键的是要了解大型软件项目设计的模式，而不是要把每一次读者分析每一行代码细节的乐趣从此剥夺掉。

另一方面，代码分析的写作风格，可以是参考手册似的；也可以是航海日志似的。我个人觉得参考手册似的代码分析是比较乏味的，读起来乏味，写起来也不免乏味，虽然它可能更有用。对于一个急着要快点结束加班工作的软件工程师来说，也许参考手册更加实用。但是对于一个想要了解这一份成功的软件背后的工作奥秘的探索者来说，一个航海日志似的代码分析，也许读起来更有味道，更能让一个程序员在键盘与屏幕之间，体会到那地理大发现的激动与乐趣。

本文后面的代码分析，就是希望能写成这样的风格。可是作者笔力有限，如有不足之处，还请读者朋友们不吝指教。

Treelang 的代码框架

读者朋友们在阅读这一部分代码分析的时候，手边最好能准备上一份 GCC 3.3 的源代码。这个源代码可以从 GCC 的站点 http://gcc.gnu.org 上获得。本文作者力图做到把整个情况像说故事一样娓娓道来，但是读者朋友们如果在适当的时候能够查阅一下源代码，可能更能把问题了解的清楚透彻。

这个 treelang 语言的实现，主要有两个 C 语言文件，把整个代码框架分成两个部分。第一部分以 tree1.c 为主，带上 parse.y 这个 YACC 源程序，组成了和 GCC 前端的接口；第二部分以 treetree.c 为主，组成了和 GCC 后端的接口。

这里首先说明一下 tree1.c 这个文件。它和上级目录中的 GCC 框架文件 toplev.c 交互作用，实现 tree1 这个执行程序的主体部分。这个 tree1 就相当于 GCC 的 C 语言前端中的 cc1 执行程序，该程序是 C 语言编译器前端的主体。

我们首先试图说明从 toplev.c 到 tree1.c 的路径。这样我们就注意到 toplev.c 中这个引人注目的 lang_hooks 变量。当然，接下来就注意到在 toplev.c 同一目录下的 langhooks.c 这个文件。我们希望在其中发现一点有趣的东西。这一共是三个文件：langhooks.[ch] 和 langhooks-def.h 其中在 langhooks.h 中定义了一堆各式各样的 struct lang_hooks_for_xxx 结构，以及最后还有一个 struct lang_hooks 结构把前面的那些 for_xxx 的结构都总括了起来。这每一个结构都是若干个至少看上去像是回调函数的函数指针。看来这就是我们要寻找的东西。那么大概就是这样了，编译器前端向 GCC 主体部分注册自己的 lang_hooks 来完成各样的任务。接下来一个自然的问题就是这个注册是如何进行的；另外一个问题就是要对这些回调函数指针进行分析了。

这个 langhooks.h 文件中关于 struct lang_hooks 结构字段的注释很详细，这里我们暂时先跳过去。等到 treelang 中具体的注册回调函数出现的时候，我们根据需要再做仔细说明。在 langhooks-def.h 文件中定义了一些这个 struct lang_hooks 结构的默认值。

现在我们进入 treelang 目录下的 treetree.c 这个文件。来察看一下在 treelang 中对 struct lang_hooks 这个结构的初始化过程。这个过程不是按照我们通常所熟悉的 C 语言的 C99 标准或者是 GCC 扩展语法来进行的。而是采用了大量的 #define 和 #undef 并结合上层目录中的 langhooks-def.h 来进行。细想一下，这是理所当然的事情，因为这是在编译 C 语言编译器本身嘛。当然就不好用到 C 语言的新的东西或者是自己做的扩展的东西。

注释开始:::::

我们以初始化如下定义的 struct sample 结构为例。

struct sample {        int member_int;        char *member_str;        void (*member_fun)(void);};
 
在 C99 中，初始化一个 struct 结构数据，使用下面这样的语法。

struct sample inst_c99 = {        .member_int = 78,        .member_str = “iloveqhq”,        .member_fun = real_fun,};
 
在 C99 标准出现之前，GCC 定义了自己的扩展，下面的例子就是按照这个 GCC 对 C 语言的扩展，来初始化一个 struct 结构数据。

struct sample inst_gcc = {        member_int: 76,        member_str: “zhaoway”,        member_fun: real_fun,};
 
在 GCC 的源代码中没有使用上面的两种办法，而是大量使用了宏定义。这个办法首先要申明一份辅助的宏定义。这些个辅助的宏定义，在一个软件项目里面，针对一个 struct 结构，只需要一份即可。

#define MEMBER_INT 0#define MEMBER_STR “”#define MEMBER_FUN NULL                                                                                      #define SAMPLE_INITIALIZER {   \        MEMBER_INT,            \        MEMBER_STR,            \        MEMBER_FUN,            \}
 
按照上面这样的办法申明了这些关于这个 struct sample 的辅助宏定义以后，在每次要初始化一个 struct sample 数据结构的时候，只需要按照如下操作即可。除了要稍微多打一些字以外，这个方法的方便程度和以上两种方法是差不多的。

#undef MEMBER_INT#define MEMBER_INT 12#undef MEMBER_STR#define MEMBER_STR “trtr”#undef MEMBER_FUN#define MEMBER_FUN real_funstruct sample inst_def = SAMPLE_INITIALIZER;
 
这样就也可以像 C99 标准或者 GCC 的扩展一样，按照成员变量的名称来初始化一个 struct 类型的数据结构了。不过话又说回来，在我们一般的软件项目中，还是应该沿着 C99 标准这个 C 语言的发展方向来走的。

:::::注释结束

接下来的线路很清楚，就是一个一个的分析这些个回调函数啦。

对用户源文件进行语法分析

这个 treelang 注册的这些回调函数在 GCC 主框架那里被调用的顺序，我们暂时还不想深入。拣有意思的先看看吧。首先关注的是 treelang_parse_file 这个函数。在 langhooks.h 里面关于这个回调函数所作的注释说明，是要它对用户的整个源文件进行语法分析。因为这个函数的返回值是 void 所以我们预期它是通过设置某一个全局变量来完成任务的；但是也有另外一种可能，就是它会把所有要做的事情都给做完，这样它也就自然不需要返回值了。这两种可能我们现在还不能确定。让我们往下看吧。

这个 treelang_parse_file 函数在 tree1.c 中定义，这是属于到 GCC 前端的接口。它直接就跑去调用 yyparse 这个 YACC 主函数了。这倒是简单，呵呵。可是要我们从 parse.y 文件中理出个头绪来，这个文件有超过 900 行的 YACC 代码，未免有点麻烦。最关键的是这中间数据的交流不大容易看清楚，不像回调函数指针这样显而易见。如果程序果真是通过设置一些全局变量来完成任务的话，我们的分析任务就有点棘手了。

注释开始:::::

在这里先说一下 tree 这个数据结构。这是 GCC 围绕着 C 和 C++ 语言的语法分析，用到的主要数据结构。所有其它语言的编译器前端，也都需要在语法分析阶段结束以后，为 GCC 生成相应的 tree 结构的数据。然后 GCC 的后端就可以从 tree 生成独立于平台的 RTL 数据结构，并随后生成相应平台上的机器语言代码。所以作为 GCC 的编译器前端，这里的主要工作就是从一个文本文件，也就是源代码，生成这个 tree 结构的数据，喂给编译器的后端。我们看到，前端是依赖于编程语言的；后端是依赖于机器平台的；中间的 tree 和 RTL 则独立于编程语言和机器平台。但是话虽如此说，这个 tree 和 RTL 数据结构也还是主要以 C 和 C++ 语言为考虑问题的中心。这是不可避免的事情。

:::::注释结束

好啦，没办法啦。我们这就开始从 treelang 目录下的 parse.y 一行一行的往下瞅吧。这个 Treelang 程序语言的语法很简单，我们看到哪儿，说到哪儿。

注释开始:::::

在看 GCC 的源代码的时候经常会遇到 GTY 这个东西。这是 GCC 内部的内存管理机制所需要的，在 C 语言代码上添加的一些类型信息，这些类型信息在 GCC 内部做垃圾收集的时候会用到。这个细节我们这里先忽略过去，以后讲到相关内容的时候再做说明。

:::::注释结束

在 parse.y 中的一些主要的产生式上所匹配的 C 函数，它们所做的工作大体上都是首先根据语法分析的结果，把自己定义的结构 struct prod_token_parm_item 里面的数据先给设置好；然后根据情况调用在 treetree.c 中定义的相关函数，生成 tree 结构的数据；这之后再把返回来的 tree 结构数据记录在 struct prod_token_parm_item 里面，并把整个结构的数据放到 symbol_table 这个单向链表上。这样看来，似乎这个 symbol_table 就是我们前面所要寻找的全局变量了。是不是在语法分析任务完成以后，就获得了这个全局变量；然后依赖于这个全局变量，后续任务才得以获得输入数据，继续往下执行呢？

我们来仔细看一看 tree1.c 中这个 symbol_table 变量的定义如下。

static GTY(()) struct prod_token_parm_item *symbol_table = NULL;
 
注意到这是被申明为 static 的变量。在 Samuel P. Harbison III 和 Guy L. Steele, Jr 所合著的 C: A Reference Manual 的英文版的第五版第八十三页上，关于 static 变量有如下说明：”On data declarations, it always signifies a defining declaration that is not exported to the linker.”换句话说，这个 static 的 symbol_table 变量，在 tree1.o 之外是看不见的。这不可能是我们所要寻找的全局变量。

可是，另一方面，除了这个变量有点像是那么一回事之外，其它的就再也没有什么有趣的变量了。这是怎么一回事呢？我们先不管它，往下看了再说吧。

那么这个 parse.y 文件大体如是啦。其它的一些具体的细节问题，牵涉到 Treelang 程序语言的具体定义，暂且不是我们的兴趣所在。粗粗的看一遍下来，这个语法分析的过程，从 GCC 的主体结构上，经由 lang_hooks 进入 treelang 部分的 yyparse 函数，这个函数按照语法定义，把编译器用户输入的 Treelang 语言的源程序分解成若干类型的小块，加以分析，生成自己定义的 struct prod_token_parm_item 结构的数据，再把这些数据一个一个串到 symbol_table 这个链表上面；这样就算完成任务了。线索从 lang_hooks 中定义的这个回调函数撤出，再度回到 GCC 的主体框架。

对了，上面还忘了说，在把用户输入的 Treelang 语言的源程序进行分解以后，在分析的过程中，按照各种类型的小块，还生成了相应的 tree 结构的数据，一起记录在各自的 struct prod_token_parm_item 结构里面，这样就一并把这个 tree 结构的数据也都放在了 symbol_table 这个链表里了。

接下来回到 GCC 的主体框架上的 toplev.c 文件。可是迷惑人的事情出现了，在函数 compile_file 对回调函数 treelang_parse_file 进行调用之后，无论是在 toplev.c 文件中，还是说在哪一个其它的回调函数里也好，似乎都并没有什么有趣的事情发生了。这让我们如何是好？看来我们只有回过头去仔细跟踪 treelang 目录下的 treetree.c 文件中的那些函数，看看它们在被 parse.y 中的产生式调用执行的时候，到底干了些什么。

语法分析的细节

根据从 parse.y 这个 YACC 文件中的产生式得来的线索，我们首先关注 treetree.c 文件中的 tree_code_create_variable 这个函数。从那个 YACC 产生式，我们估计这个函数是为一个变量申明而构造必要的 tree 数据结构。这个函数有 100 行不到的源代码。我们来仔细的看一看。这个函数使用了从 GCC 的框架结构里面来的关于 tree 数据结构的一些 API 接口。我们目前所最感兴趣的，就是这个函数在利用这些接口函数构造一个和所对应的 YACC 产生式相当的 tree 结构数据以外，还干了些什么。我们之所以关心这个”以外”，是因为目前我们最想了解的，是这个从 Treelang 语言的源程序开始，到一连串的 tree 结构数据，然后是怎么变成 RTL 结构的数据的。只有在有了这样一个概观以后，我们对 GCC 前端的编写方法才能算有了一个初步的大概的了解。

根据这样的思路，我们很快就看清楚，在这个 tree_code_create_variable 函数中，在设置好若干个局部的 tree 结构的数据以后，引人注目的在一个 if 语句的分支中调用了 rest_of_decl_compilation 这个函数。而且在这个函数被调用返回以后，似乎不再有重要的事情发生了。这个函数来自于 GCC 框架结构上的 toplev.c 文件。这样的话，根据我们前面的分析，这个函数里面应该会隐藏有我们的主要问题的答案。也就是说，在 YACC 文件 parse.y 把用户提供的 Treelang 语言的源文件肢解以后，在 treetree.c 中的相应的函数，为之生成了相应的 tree 结构数据，而在现在我们所关注的这个 rest_of_decl_compilation 函数（以及在这个 if 语句的另一个分支中出现的一系列相应的函数）中，应该会完成从 tree 结构的数据到 RTL 数据的翻译。

从另一个角度补充一点，程序的执行线索是如何从 GCC 主框架进入 parse.y 中的呢？这一段我们前面分析过了，现在再来提醒一下。这是从 GCC 的框架结构，进入到 treelang 这个 GCC 的语言前端模块注册的 lang_hooks 结构的数据，找到相应的回调函数，最终找到 parse.y 这个 YACC 程序的入口 yyparse 函数的。在 yyparse 之后，我们看到程序的主线索进入了 treelang 目录下的 treetree.c 文件中的函数。最后，我们重新又追踪到 GCC 主体部分的 toplev.c 文件中的函数。现在我们的整个图景的大轮廓就快要完全弄清楚了。

GCC 前端的全景图

终于，我们在 rest_of_decl_compilation 函数中，看到了一系列的和 RTL 相关的函数调用。稍微仔细的看了一遍之后，我们有把握得出这个结论了。我们在本文的开头部分，曾经猜想 GCC 的主体部分在要求 GCC 这个 Treelang 语言前端从用户提供的 Treelang 语言的源程序文本，经过语法分析，得出相应的 tree 结构数据以后，会把这个数据通过函数返回值传回给 GCC 的主体程序，或者设置一个全局变量，这样就算完成任务了。但是事实上，经过我们上面的分析，发现不是这么一回事。

相反的，在 Treelang 这个语言前端得到需要的 tree 结构的数据以后，继续往下的运行，这完全是 Treelang 前端必须自己负责的任务。这个 GCC 前端必须自己调用 GCC 主体部分提供的，用来从 tree 结构数据生成 RTL 结构数据的函数接口，以完成从 tree 结构数据到 RTL 结构数据的翻译过程。这样，这个 GCC 的语言前端的任务才算完成。换句话说，GCC 的这个语言前端承担的角色是非常的主动的。很明显，这样的设计提供给我们极大的灵活性。关于这一点，我们以后会逐渐看到。

小结

本文限于篇幅，只大略讲述了 GCC 前端的框架结构，给出了一个粗略的全景图。在以后的几篇文章中，我们将进一步探索 GCC 的主体部分为 GCC 前端所提供的 API 函数和数据结构。并利用这些知识，探索一下为 GCC 编写一个 Scheme 语言前端的可能性。在这一系列文章结束的时候，希望能使得读者朋友们对 GCC 以及程序语言的本质有一个更加深刻的了解。也希望 GCC 的前端的作者人数，就能和 Linux 内核模块的作者人数一样多。我们的座右铭是：每一个人都是程序员；每一个人都能加载自己编写的内核模块；每一个人都能使用自己实现的编程语言！（不要害怕，这只是一句玩笑话。呵呵。）

在技术内容以外，本文也探索了开放源码运动所需要的技术文档的一种写作模式。开放源码运动为我们带来了大量的自由软件的源程序。对于用户来说，需要文档讲述如何使用这些自由软件；对于程序员来说，则需要文档讲述如何才能理解并真正的掌握这些自由软件的源程序。这第二种文档的写作，不是一件容易的事情。作者本人在经常阅读解释自由软件的源程序的内部运作机理的文档的过程中，总是觉得这件事情应该可以有办法做的更好。本文就是作者的一个尝试。希望读者朋友们给我来信，不仅仅讨论 GCC 的技术问题，也欢迎对作者的写作方式提出批评与指教！

参考资料

Internals of the GNU Compiler Collection http://gcc.gnu.org/onlinedocs/gccint/ 这其实也就是 info gccint 的内容。这份文档是除了源代码以外最权威的资料了。不过它的可读性恐怕不是那么好。初上手阅读的时候，恐怕会非常困惑的。

The GNU Treelang Compiler 手册，这其实也就是 info treelang 的内容。这个作为例子的 Treelang 程序语言基于 Tim Josling（见下）为了阐明 GCC 前端的编写方法而发明的一个玩具编程语言。

Sreejith K Menon 编写的 GCC Frontend HOWTO http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html 被收录在 The Linux Documentation Project 的 HOWTO 文集中。这份资料可能是可读性最强的了吧？当然，这是说除了本文之外啦。:-)

Using, Maintaining and Enhancing COBOL for the GNU Compiler Collection http://cobolforgcc.sourceforge.net/cobol_toc.html 这是由 Tim Josling 领导的 COBOL for GCC 项目的文档，其中原先由 Joachim Nadler 所编写的第十四章，后来由 Tim Josling 从德文翻译成英文；这一章讲述了 GCC 前端的编写方法。

Using and Porting GNU Fortran 手册 http://gcc.gnu.org/onlinedocs/g77/ 中关于 Front End 的一章也讲述了我们感兴趣的内容。

自由大百科全书 Wikipedia 中关于 GCC 编译器家族的条目 http://www.wikipedia.org/wiki/GNU_Compiler_Collection 对 GCC 有个概括介绍。关于 GCC 内的 RTL 数据结构的条目 http://www.wikipedia.org/wiki/Register_Transfer_Language 以及关于 GCC 的前端使用的 Tree 数据结构的条目 http://www.wikipedia.org/wiki/GCC_Abstract_Syntax_Tree 也都值得一看。

用 Doxygen 文档生成工具制作的 GCC Source Documentation http://www.nondot.org/gcc/ 有兴趣的话也可以看一看。

在阅读大型的 C 语言项目的源代码的时候，手头有一本好的、全的 C 语言参考手册也是很重要的。

关于 C 语言的一本比较好的书是 Samuel P. Harbison III 和 Guy L. Steele, Jr. 合著的 C: A Reference Manual 第五版。这本书的英文影印版最近在国内出版了。作者之一 Guy L. Steele, Jr. 是 Scheme 编程语言的发明人之一，也是 Java 语言规范的作者之一，更是 ACM 的 Grace Murray Hopper 奖 1988 年的获得者。