2014开源开发工具大会见闻录

上午因为家里有事,没能看到上午两个精彩话题,也辛苦了明杰和吴伟以及开源协会的各位同学。

中午到达,下午第一个演讲是ARM来的王哲宇介绍的pyOCD,中午发困导致精神松懈,所以体会不深,整体感觉是一个用PYTHON写的OCD软件。
osdt2014_1
附图一张,总让人觉得快要从讲台上掉下来的王同学。

然后就是一代宗师LUBA的话题,因为一些不可抗力,话题从Xposed for ART on Android换成了Beyond Compiler Engineering,一位同学竟然愤然提起了抗议:“原来不是ART话题吗?”。
我现在真想对这位同学说,ART什么都是浮云,没准哪天突然就跟Dalvik一样就随手被GOOGLE换掉了。但是LUBA话题谈的显然是能走的更远的。
话题前一段总结起来就是摩尔定律逐渐衰落后给编译器带来了巨大的机会,最后他还拿出了一张图,对今后40年内,哪一年哪项技术会推动前进,没错具体到年的,不知道这张图是怎么来的,不过台下所有弄编译器的同学心里都兴奋了,沸腾了。明杰同学之后就一直在问我:“编译器真的这么有前途?”
然后话锋一转,大师开心的说,可以开始讲技术了。之后对GCC系和LLVM系进行了比较和分析外加小八卦。
osdt2014_2
忙着创业每天只能睡3个小时,仍然准备了双份精彩话题(有一份Xposed不能讲)的LUBA大神。

接着是硬件人中的软件人软件人中的硬件人——翟哥的话题。我刚进场没看见他,后来才知道,他想演示的板子还没搞定,带着表坐在最后忙活着呢。
最后到时间时还是没搞定,在我的建议下改为现场举起板子让大家看一眼。
整个话题都围绕OPENOCD展开,不过我主要注意点集中到了这玩意脚本支持的部分用的TCL,于是作为一个饱受GDB testsuite中TCL虐待的GDB开发者,在话题讨论时对使用TCL脚本进行了丧心病狂的吐槽,还试图拉齐姚同学一起来吐槽。
齐姚同学不愧是和稀泥的高手,分析说是因为OPENOCD是德国人作的,德国人作事力图严谨,肯定会在通读过整个TCL手册才会开弄。
osdt2014_3
挥舞着板子,致力于向广大屌丝码农提供全栈开源的方式(软硬件都开源)搭建ARM处理器的JTAG调试环境的翟哥。

下午最后一个常规话题是专注于模拟等方向的SKYEYE开发者康老师,小小炫耀一下,我曾经也是SKYEYE开发者。
他的话题比较详细的介绍了符号执行以及其和其他程序分析技术的区别等等,之后又演示了他们的Android的全系统符号执行工具-Android_S2E。
osdt2014_4
话题时间对他来说永远不够,被我们安排到最后一个可以随便拖时间很开心的康老师。

之后两个是闪电演讲,先是一位阿里的同学讲了JAVASCRIPT的相关内容,我走神了没太听仔细,希望看视频能仔细看看。另外阿里工具组我们早有耳闻,希望明年能看见他们的常规话题。
osdt2014_5
我没记住名字的阿里同学。

之后是我的老友,和我一样也是曾经的模拟器开发者,现在专注Android安全的在读博士亚金。对他话题的提问都是问他用什么系统的手机,用什么Android ROM的。
osdt2014_6
专注吓唬Android用户,看我站在台下忍住没黑我小米的亚金。

之后是欢乐的抽奖活动,然后就是更欢乐的演讲者聚餐(最快乐的是吐槽了没到场的同学,老唐我们没说你啦,嘿嘿!),明年再见啦各位。

关于”error conflicting types for function”编译错误的分析

在使用gcc编译C程序时,有时会碰到“error: conflicting types for ‘function’”的编译错误。从字面意义上理解,是说函数的定义和声明不一致。在这篇文章里,我就对这个错误做个简单的分析(使用的gcc版本是4.9.0)。
(一)首先我们看一个函数的定义和声明不一致的例子:

#include <stdio.h>

int func(int a);

int func(void) {
    return 0;
}

int main(void) {

    func();

    return 0;
}

编译程序:

gcc -g -o a a.c
a.c:5:5: error: conflicting types for ‘func’
 int func(void) {
     ^
a.c:3:5: note: previous declaration of ‘func’ was here
 int func(int a);

可以看到由于“func”的声明和定义不一致(一个有参数,一个没有),所以编译时出现了这个错误。

(二)最近我在把一个老程序从Solaris移植到Linux,编译时也出现了这个错误。但是我发现函数在头文件里的声明和函数定义是完全一样的,这就令我很奇怪。查了将近一天时间,最后得到结论是函数参数类型在函数声明后定义了。简化的代码如下:

#include <stdio.h>

void func(struct A *A);

struct A {
        int a;
};

void func(struct A *A)
{
        printf("%d", A->a);
}

int main(void) {
        // your code goes here
        struct A a = {4};
        func(&a);
        return 0;
}

其中“structure A”的定义放在“func”函数声明之后了,而func函数的参数是“structure A*”类型。编译结果如下:

gcc -g -o a a.c
a.c:3:18: warning: ‘struct A’ declared inside parameter list
 void func(struct A *A);
                  ^
a.c:3:18: warning: its scope is only this definition or declaration, which is probably not what you want
a.c:9:6: error: conflicting types for ‘func’
 void func(struct A *A)
      ^
a.c:3:6: note: previous declaration of ‘func’ was here
 void func(struct A *A);
      ^

可以看到也输出了“error: conflicting types for ‘func’”的编译错误,也许编译警告可以给一点提示吧。

我检查了一下程序的Makefile,所有编译警告都关掉了,也许是编译警告太多了吧。

为什么gcc在64位Solaris上编译出来的程序默认是32位的?

最近发现一个问题,gcc在64位Solaris上编译出来的程序默认是32位的,而在64位Linux上编译出来的程序默认就是64位的,觉得有点奇怪,就在stackoverflow上问了一下(http://stackoverflow.com/questions/25560539/how-does-gcc-determine-if-to-generate-a-32-bit-or-64-bit-executable-file-by-defa)。其中一个回答给出了一个链接(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58833),原来这是Solaris有意而为之。总结一下,有以下几点:

(1)64位的gcc或程序不一定比32位运行快;

(2)Studio程序默认是32位的,gcc最好和它行为保持一致;

(3)从用户体验出发,以前都是默认生成32位程序,现在一下变成64位,用户可能需要改很多配置;

(4)64位Solaris位的gcc可以既编译32位,又编译64位,看用户自己的选择了。

2014开源开发工具大会(原HelloGCC技术讨论会)

2014开源开发工具大会见闻录

【大会简介】
2014开源开发工具大会(原HelloGCC技术讨论会)是由HelloGCC(www.hellogcc.org)工作组举办的年度开源技术大会。我们希望通过自由,开放,共享的方式来增进大家相互的交流。目前话题主要涉及开源工具链,开源开发工具方面。感谢演讲者为我们贡献精彩的话题 ,感谢各单位和朋友对我们的赞助和支持,欢迎大家免费报名参加。
往年活动:
*) HelloGCC Workshop 2013: http://www.hellogcc.org/?p=33518
*) HelloGCC Workshop 2012: http://linux.chinaunix.net/hellogcc2012
*) HelloGCC Workshop 2011: http://linux.chinaunix.net/hellogcc2011
*) HelloGCC Workshop 2010: http://linux.chinaunix.net/hellogcc2010
*) HelloGCC Workshop 2009: https://sites.google.com/site/hellogccworkshop/hui-yi-ri-cheng

【日程安排】

2014年9月13日(周六)中科院软件所5号楼4层大会议厅
9:00 – 9:30 入场、签到
9:30 – 9:40 嘉宾介绍、致谢
9:40 – 10:30 话题:Performance Testing for GDB,齐尧
10:30 – 11:20 话题:Design and Implementation of GCC Register Allocation,程皇嘉(Kito Cheng)
11:20 – 11:30 抽奖
午餐、休息
13:30 – 14:20 话题:pyOCD — gdbserver for ARM CMSIS-DAP,王哲宇
14:20 – 15:10 话题:Xposed for ART on Android,唐文力(Luba Tang)
15:10 – 15:40 自由讨论
15:40 – 16:00 话题:开源工具构建ARM JTAG调试环境,翟京(Orson Zhai)
16:00 – 16:50 话题:Android的全系统符号执行工具-Android_S2E,康烁
16:50 – 17:20 自由话题(闪电演讲,现场报名)
17:20 – 17:40 抽奖,合影

题目:Performance Testing for GDB
演讲者:齐尧
简介:
GDB development process has no standard mechanism to show the performance of GDB snapshot or release is improved or worsened. Performance regressions do show up periodically.
We recently add a new performance testing framework in GDB. In this session, we introduce this performance testing framework and show how do we use it to track GDB performance during development. Then, we show writing performance test cases on top of this framework and performance problems exposed by these cases.
Finally, we discuss about adding more test cases and fixing other performance problems in the future.

题目:Design and Implementation of GCC Register Allocation
演讲者:程皇嘉(Kito Cheng)
晶心科技(Andestech)工程師,目前專注於 nds32 CPU 的 GCC,進行效能及程式大小的調校。
简介:Register Allocation 在編譯器後端是個相當重要的階段,其結果將直接影響最終程式的效能以及大小,而 Register Allocation 在 GCC 中一直是個難以對付的東西,所幸近年來有 Red Hat 的高手將其改善,於 GCC 4.4 時將原本的Local/Global 兩階段 RA,轉換為 IRA,並且在 GCC 4.8 時LRA 正式上路,預計將慢慢取代 GCC 中數一數二複雜的Reload,而本報告中從基礎的 Graph Coloring-based Register Allocation 的理論介紹,並將其對應回目前GCC IRA/LRA 的實作,一探其運作原理。

题目:pyOCD — gdbserver for ARM CMSIS-DAP
演讲者:王哲宇
简介:pyOCD是目前mbed社区为M系列MCU所提供的调试服务工具。该工具主要基于CMSIS DAP接口,为不同的M系列厂商提供了统一的调试接口。pyOCD和目前的GNU Tools for ARM Embedded Toolchain相互结合,为用户提供一个完整的M系列MCU的开发工具。此次主题从嵌入式调试技术的现状展开,介绍一些比较新颖的调试技术例如在MCU上的本地gdb stub,以及嵌入式gdb server和PC上的remote stub的一些异同。详细介绍pyOCD的内部实现和各模块的功能,同时也会简要介绍一下pyOCD目前在Launchpad上的发布情况,并鼓励开源爱好者们参与到pyOCD的贡献中来.

题目:Xposed for ART on Android
演讲者:唐文力(Luba Tang)
简介:本次 talk 會介紹 Xposed 移植到 ART 平台上所會遇到的問題與對應的解法。
Xposed 提供 Android 上一個可以跨 framework 的平台,大大縮減了 Android 系統維護的成本。
然而目前 Xposed 尚無法再最新的 Androdi ART 平台上運作。
本次 talk 會介紹 Xposed 在 Dalvik 上運作的原理,以及移植到 ART
平台上所會遇到的問題與對應的解決方案。如果時間允許的話,也會順便 demo 目前的成果。
相關資料 http://repo.xposed.info/module-overview

题目:开源工具构建ARM JTAG调试环境
演讲者:翟京(Orson Zhai)
简介:
采用全栈开源的方式(软硬件都开源)搭建 ARM处理器的JTAG调试环境。
开源软件 – OpenOCD, GDB,KiCAD
开源硬件 – Openboard

题目:Android的全系统符号执行工具-Android_S2E
演讲者:康烁
简介:
1、符号执行的介绍和应用领域
2、全系统符号执行S2E
3、移植全系统符号子执行平台S2E到安卓的过程和方法
4、演示一个在Android_S2E上符号执行Android的本地程序的例子

【大会地址】
北京市海淀区中关村南四街4号中国科学院软件研究所5号楼4层大会议厅
交通图

【赞助单位】

钻石赞助商 Skymizer
白金赞助商 Xiaomi_Logo
互动出版网
CSDN-CODE-logo
赞助商 ARM
媒体支持 InfoQ
CSDN
弯曲评论
ChinaUnix
合作单位 http://www.is.cas.cn/
20131015034226346

【餐饮、礼品】

午餐 前100名签到报名者
茶水饮料 会场提供
小米盒子增强版 抽奖6个
CSDN蓝牙音箱 抽奖3个
CHINAPUB礼卷 前150名签到报名者
CHINAPUB图书 抽奖10本
CHINAPUB礼品 展位领取

编译gdb注意事项:一定要用一个干净的build文件夹

上周收到gdb的通知邮件,说gdb 7.8已经release了。作为gdb的忠实用户,自然是体验一下了。我赶紧下了一个版本,然后build了一下,结果在最后link阶段,出了错误:

gcc: unrecognized option `-rdynamic'
ld: warning: file /usr/local/lib/libiconv.so: attempted multiple inclusion of file
Undefined                       first referenced
 symbol                             in file
observer_attach_exited              cli-interp.o
observer_notify_signal_exited       infrun.o
observer_attach_sync_execution_done cli-interp.o
observer_attach_command_error       cli-interp.o
observer_notify_signal_received     infrun.o
observer_attach_end_stepping_range  cli-interp.o
observer_attach_no_history          cli-interp.o
ptid_match                          remote.o
observer_notify_end_stepping_range  infrun.o
observer_notify_exited              infrun.o
observer_notify_no_history          infrun.o
observer_attach_signal_exited       cli-interp.o
observer_notify_command_error       event-loop.o
observer_notify_sync_execution_done infrun.o
observer_attach_signal_received     cli-interp.o
ld: fatal: symbol referencing errors. No output written to gdb
collect2: ld returned 1 exit status
Makefile:1334: recipe for target 'gdb' failed
make[2]: *** [gdb] Error 1
make[2]: Leaving directory '/export/home/nan/build_gdb/gdb'
Makefile:8667: recipe for target 'all-gdb' failed
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory '/export/home/nan/build_gdb'
Makefile:831: recipe for target 'all' failed
make: *** [all] Error 2

gdb的编译过程一向是最简单的,link错误我还是第一次碰到。我先是在gdb的IRC里讨论,接着又自己debug,检查代码文件和脚本,结果最后得到的结论是:因为我所用的build目录之前是编译7.7.1版本的,我因为偷懒,没有清空,导致现在编译7.8版本时会有问题,原因应该是link的还是7.7.1的目标文件。

最后得到的经验是:在编译gdb(或是其它软件)时,一定要准备一个干净的build文件夹,否则可能会有你意想不到的问题,像我碰到的在link阶段出问题还好办,如果在执行阶段出了问题,可就更难查了。

注:build文件夹是为了保持源码的干净,通常在源代码文件夹外,新建一个build文件夹,然后所有的configure,make操作等都在这个build文件夹下进行。例如:

mkdir build_gdb;
cd build_gdb;
../gdb-7.8/configure
make
make install