HelloGCC 2011 Workshop 见闻

HelloGCC是下午1点30开始,arm的四位同事是从上海飞过来的,十点半到的北京,我们一起在物科宾馆吃午饭,这个宾馆的餐厅很不错,午饭非常愉快。

他们team来了四个。其中有两个人都是之前在maillist见的,今天终于见到真人了。不过,他们见到了teawater真人的时候,还是比较激动的,都用了一句 “久闻大名”,见到我的时候,都来了一句“哦,你叫 qi yao,不叫 yao qi啊”,好像很多人第一次见我,都会有这样一句。后来吃饭lingkun和liujia也来了,linkgun帮我们贴了很多引导箭头,实在也辛苦了。

话题范围也比较广,从京沪高铁到arm maintainer;从linaro到auto vecterization和八卦出来的那个以色列美女; 吃饭吃到一半,teawater和ericfisher去会场准备去了,我们剩下的接着吃饭,这里感谢一下他俩。这里还有负责会场的ChinaUnix的老周,十分敬业。


吃完饭,我们一起到了会场,也就基本没有什么事情了。ericfisher和pzhao在准备开场介绍,方方面面都要考虑到,不容易的。

一点半,活动开始,我们的主持人pzhao上去介绍了一下我们的活动,一开始有点紧张,后来就好了。接下来,是中科院开源协会的讲话,一会就讲完了。

我们的话题就正式开始了,

第一个话题 介绍gcc后端的工作流程。没有废话,直接进入主题。感觉缺少一点outline。可能听众都不太清楚这个话题的提纲是什么。第一页,非常有杀伤力,这样讲gcc的,绝对体现大牛实力。用了一个很好的图来介绍gcc内部的流程和结构。如果没有gcc后端的经验,可能不好理解。这个slide很赞的地方就是用一个简单的例子来介绍gcc各个阶段的不同表示。rtl pattern太小了,我在第一排,我看不清。
生成的rtl依然看不清。中间有一页是关于move合法性,我个人对这个关于move的内容很有兴趣,不过有点遗憾,没有在这个上边讲太多内容。 后来,那个字典比喻很好。关于move,也许这里还有更多的东西,我们可以深入研究一下。

 

顺便说一句,中间有一个女孩特意跑来让我们提示演讲者,不要离话筒太近,不然音响效果不好,都听到喘气声了。这里感谢一下那位女孩。

slides突然跳到了llvm感觉很突兀。后边的很精彩。总体来说,技术内容十分充足,但是表达方式需要改进。slides被有些生硬的划分成了若干部分,除了我们几个经常一起交流的,可能其他人很难把这些部分,联系在一起吧。

第二个话题是 arm 上海的Joey Ye讲的。 一个很不错的开场”good news vs bad news”。对他们每个team成员介绍。


他对arm toolchain 进行了介绍,也许是我的背景比较了解吧,所以感觉一切都很自然,很容易理解。然后他介绍了,他们那个gcc branch和gcc mainline以及gcc 4.6 branch的关系,是一个很好的例子。国内,以前也没有人说过如果自己做一个branch,patch应该是怎样merge的。这个我也觉得很熟悉。我在这里简单说一点吧,关于自己的branch。gcc的开发模式,是这样的,比如gcc 4.6 branch还在,同时gcc mainline (4.7)也在开发,但是mainline还没有release过,所以,一般没有人在mainline build 然后release给自己的客户。好的方式是在gcc 4.6 branch的基础上,创建自己的branch。这里,自己的branch的原则是,尽可能少的携带自己local的patch,除非自己的branch十分需要,但是upstreams (gcc 4.6 branch 或者 gcc trunk 4.7)不要这个patch的情况。所以,一旦在自己的branch 有了patch,首先想到的是,contribute到mainline,如果不适合mainline,那么就要试图contribute到gcc 4.6。这样,gcc 4.6 branch接受了这个patch后,就可把这个patch backport到自己的branch。基本上,所有的branch都是 这样run的。

中间讲到了一个如何从头开始build armtoolchain的slide很有意思。应该是在什么地方得到他们的build文档和脚本,然后可以从一个新的ubuntu的环境中,按照文档中描述,build出一个arm cross toolchain的binary。这样很好,正如“Build or Buy?”讲到的,build自己的toolchain是十分复杂的事情,能有这样的文档和脚本,的确很好。

第三个话题是关于displaced stepping的。可能大家对这个领域不是很熟悉,所以没有什么太多的问题。对过程中,那个板凳的比喻印象深刻。

 

第四个话题是关于llvm的。讲得很好,很清楚,一看就是做学问的。对自己的工作和别人的工作都讲述的十分客观。犹豫我对背景没有什么了解,问了一些很基本的问题。里边吸引我的地方就是可以为自己的arch在llvm中添加pass,来达到自己的目的。我觉得这个很好。本来想问他们那些工作是否曾经尝试提交到upstream,后来记了。我觉得是很好的工作,如果愿意贡献出来,也是我们国人的骄傲。

在benchmark的图表上,要是能再细致一点,把那个总计时间,分开,这样比较起来更有指导意义一些。

第五个话题是关于 gcc plugin。
对插件的历史和之前的一些争论做了很好的总结和评价。然后就在介绍他自己做的那个gcc 插件,台下掌声不断。的确是我们的榜样。其中一个人的问题很好,关于vcg是否能用dot生成图像,现在vcg还没有。不过我个人觉得dot是一个很简单的语言,而且它的layout做的很好,不过作者的担心是dot只能编译成为pdf或者jpeg才能看,没有直接浏览的办法。

最后的问题,现在很多插件还都是处在一个玩具的状态,好像没有一个成熟的插件。的确现在是这个,我觉得,gcc的版本变化造成了plugin的接口变化,这样的一个趋势导致没有人敢做插件,因为接口总在变。

个人看法:gcc community还在犹豫,就是又想打造很好的生态系统,让别人来参与,但是又担心,别人用了gcc的功能去做自己的商业工具。我个人一直不同意插件需要gpl。之前gnu的软件使用gpl,能够成功,是因为软件及其复杂,比如gcc或者gdb,即使别人能有代码,依然有很多别的技术门槛使得只有source cdoe是无法工作的。就像”Build or Buy?”那个文章里边讲到的。但是gcc plugin都不会很复杂,对于一个不是很复杂的软件,如果公开了源代码,就没有任何的商业价值了。不过,GCC作为GNU和GPL的标杆性项目,是一个很重要的阵地,所有人都比较慎重,保守一点可以理解。

最后到了抽奖,两个pad的大奖。我还真想要个pad,但是抽奖又没有我。不过还是恭喜那两位幸运听众。我们的主持人pzhao还是大度的,自己被抽到了,但是还是把机会让给了别人,值得表扬。 hellogcc 2011会场部分也就这样结束了。有点小小如释重负的感觉。

人都散去了以后,我们合影留念,我们私下聊天,交流一些做GNU toolchain的心得,很不错。我和arm的Terry Guo 聊了很多。然后我们建议大家一起留影纪念。

第一排从左到右,依次是 chengbin,ericfisher,yao,teawater,pzhao,老周(ChinaUnix)。第二排从左到右依次是lingkun,wuwei,liujiangning,Joey Ye, 不认识,xuguowei,不认识,Jia,Terry Guo。

然后我们就一起去吃晚饭。workshop已经圆满结束了,我们好像更有心思聊天了。当然,只要teawater在,我们都总有话说。我们聊了聊某位gdb maintainer总在用一种没有任何建设性意见的方式去review别人的patch,这样的确很不友好。大家还对明年的活动提出了各种各样的想法,很有意思。最后,吃饭完毕,都到了晚上九点了,一天都过去了。HelloGCC workshop 2011就这样结束了。

小技巧:使用预处理选项-P

xmj@hellogcc.org

有时编译程序会遇到如下所类似的错误,

In file included from foo.c:15,
from a.h:45,
b.h:53: error: ... ...

为了查看出错原因,可能会需要先手动编译生成相应的预处理文件,然后查看预处理文件中的代码。比如,对于

gcc -o foo.o -c foo.c

可以先运行

gcc -o foo.i -E foo.c

来生成foo.i预处理文件。然后,还可以尝试手动编译,修改这个预处理文件。

但是,由于生成的预处理文件中含有行号标记(linemarker),所以,运行

gcc -o foo.o -c foo.i

所得到的错误信息还是跟最初的一样,如果可以将预处理文件中的行号标记都去掉,似乎会有些帮助。

幸好,gcc提供了这个选项:

-P
Inhibit generation of linemarkers in the output from the
preprocessor. This might be useful when running the preprocessor on
something that is not C code, and will be sent to a program which
might be confused by the linemarkers.

运行

gcc -o foo.i -E foo.c -P

即可。

读 “GNU Toolchain for Embedded Development: Build or Buy?“ 有感

这个题目是在有点老套了,让我想起了初中时代,写作文的题目。今天无意中看到了这样一个white paper,Mark Mitchell写的。看了一遍,还是有些思维的跳跃,跟大家分享一下。原文 “GNU Toolchain : Build or Buy?” 需要注册下载。

我在这里也不评论到底是应该build还是应该buy,这个结论也不是我这个文章的重点。我就是想看看从这篇文章里边,我们能知道一些GNU toolchain开发的状况。

这篇文章14页,不长。跳过前边,直接从第四页开始,介绍了Building The Toolchain,这个是一个复杂的过程。自己build 过 toolchain的人都应该有这样的感觉,

    需要了解每个toolchain component的版本。有些版本的某个component可能有bug,或者某两个component在某个两个版本上,不能一起使用,等等。这些问题需要在一开始就知道。
    应用哪些patch?toolchain component可能有问题,所以在某个版本后,才会有相应的patch fix,那么那些patch应该用,用了以后会不会带来新的问题,等等,这些问题也要考虑。
    configure的选项。虽然几乎所有的gnu toolchain component都是遵循 configure make make install的过程,但是每个都有十分复杂的configure 选项。

上边这些无非是告诉我们,build toolchain就是一个十分复杂的事情。但是我们可以看出,这些东西从侧面告诉我们,这些就是一个依靠GNU toolchain生存的公司或者部门的必须知道或者精通的知识和技能。之前和朋友聊过,说,我们什么时候也能开一个toolchain 的公司,我们当时开玩笑说,等有了global maintainer再说吧。其实上边这些就是开toolchain公司的一些必要条件。

文章接下来讲了toolchain validation。里边很多都是介绍GNU toolchain怎么测试的,我这里就跳过了。有意思的部分是“分析和修正test failure”。对于toolchain这样的严格系统软件,很多时候,是一种 “bug-fix-driven development”,每一个release至少要保证没有严重的错误,然后再保证一些性能的提高或者新的特性。所以,在toolchain这个行当里边,“修bug”比别的行当重要的多。在我之前的工作中,修bug好像是一个很没有技术含量的事情,可能因为那些bug也没有什么技术含量。GNU toolchain的工作,很大部分是在修bug,而且我现在认为,修bug是进步最快的一种方式。

好,回到toolchain validation,在测试中发现了fail,就需要fix。文章中给出了一个最“乐观”的方式,定位出问题的component,理解代码,发问题到list,自己修正,把patch发送到list。但是,实际上,这样的方式对大多数人,行不通的。就“理解代码”这样个事情,就很复杂,toolchain的代码量那么大,而且之间还有一些交互,理解代码是很难的事情。 总之,能够自如的使用那个最“乐观”的方式,是自如的加入GNU toolchain开发的一个必要条件吧。

希望这样一个文章不会让我们这样在toolchain行当里边挣扎的人感到绝望,相反,希望我们能看到一些曙光,希望和方向。我看到了,你呢? 🙂

HelloGCC WorkShop 2011

报名网址:http://linux.chinaunix.net/hellogcc2011

2011年9月24日(周六)下午

【演讲主题】

1、Introduction to GCC Backend

演讲者:刘佳

拿一个简单而具体的例子介绍了GCC的工作流程,尤其GCC后端的工作流程。主要介绍了gcc是怎么处理rtl模版从而生成代码的。最后通过LLVM的后端对比一下异同。

2、GNU Tools for ARM Embedded Processors

演讲者:叶锦云

简介: 作为维护和改进GCC上ARM架构的工作的一部分,ARM将维护一个GCC工具链的分支,特别针对嵌入式内核,如ARM Cortex-R/Cortex-M系列。此外,ARM将定期的从这个分支上构建、测试并发布二进制包。发布的包可以任意的整合到工具链中,或直接使用。这个话题将主要介绍ARM建议的工作模式和计划改进GCC的要点。您将了解到更多关于GCC在嵌入式方面的应用及挑战。并期待听到您独特的见解。

3、多核时代更快断点 — Displaced stepping以及对Thumb-2指令集的实现

演讲者:齐尧

简介: 多核处理器逐渐成为主流,一些传统的调试技术无法适应新的编程方式(比如多线程编程)。如何实现一种对多线程程序更加快速的断点机制进入的调试器开发人员的视野,而displaced stepping也就应运而生。本文介绍了displaced stepping的工作原理和实现方式。结合ARM Thumb-2指令集,讲述了如何为一种新的指令支持displaced stepping。同时还介绍了基于displaced stepping的GDB non-stop工作模式。最后,会对今后的多线程调试或者多核处理器调试做一个展望。本文会帮助读者理解displaced stepping的机制和移植工作,也为读者从GDB的内部剖析了non-stop工作模式。

4、TCG与LLVM生成二进制代码性能分析

演讲者:徐国伟

简介: 现在很多模拟器采用了LLVM作为二进制翻译的后端,相对于解释执行的模式,得到了巨大的性能提升,而且由于LLVM的多平台性,通用性可以做的很好。本文基于Skyeye和Qemu两种模拟器,给出了Benchmark程序在用户态模拟下的TCG和LLVM生成的宿主机代码与x86本地编译的代码性能对比。

5、走进GCC插件时代

演讲者:邢明杰

简介:GCC从4.5开始支持插件,使得开发者可以使用插件技术来扩展编译器功能,一时间也出现了一些第三方插件。插件技术的引入,是否意味着GCC又进入了一个新的时代,它又会带来哪些问题?本话题介绍了GCC 插件技术的原理,实现,以及现有一些第三方插件;同时,也和大家分享一些插件技术背后的故事。