Linux手机DIY.库文件专题.交叉编译的浮点问题

 Linux手机DIY.库文件专题.交叉编译的浮点问题

草木瓜  于 2006-11-9

一、序

  交叉编译过程的浮点问题可畏老大难，各个gcc的版本兼容性不一，所对应的patch效果差异又很大。这对构造不同于E680的E600编译环境造成了很大麻烦，这里我对尝试的过程做下描述，以供参考，毕竟中文资料少得可怜。

二、重要提示

    为了方便更好的理解本文，提供下面链结。
    全系列的文章地址，手机应用开发专栏：http://blog.csdn.net/liwei_cmg
    相关的重要成果的下载地址：http://play.younet.com/view.php?tid=24045

三、浮点问题的由来

  MOTO E680 系列，夏新E600和飞利浦968 等等手机，皆使用Inter Xscale的
处理器，所采用的指令集也是armv5tel。

  E680G 版本信息
  Linux (none) 2.4.20_mvlcee30-mainstone #1 Jan 1,2003 armv5tel unknown
  E600 版本信息
  Linux c8k 2.4.19-rmk7-pxa2 #1 Thu Mar 23 17:56:36 CST 2006 armv5tel unknown
  968 版本信息
  Linux c8k 2.4.19-rmk7-pxa2 #1 Fri Dec 9 16:42:58 CST 2005 armv5tel unknown
  
  Inter Xscale这款新型高性能、低功耗的微构架兼容ARMv5TE ISA指令集，
不过不支持浮点指令集。这是为了节省处理器芯片体积和降低运行功耗，XScale
体系结构没有实现昂贵的浮点运算部件和除法部件。这些是嵌入式应用中不常用
的运算。当需要这类运算时，要通过软件方法实现。
  浮点运算要大大复杂于整数运算，没有浮点运算单元会有什么问题？
  
  我们来看一个例子：
  E680/E680i/E680g CPU都是ARM系列的Intel xScale PAX270。MP3解码有两种
方式，一种是基于浮点运算(如MPG123)，另一种则是基于整数的，即libmad (MPEG
audio decoder library)。浮点的解码，单精度浮点小数可以精确到小数点后45位，
不过要求CPU有FPU单元。由于E680系列本身的限制，只能使用软浮点，libmad是用
的fixed-integer，通过整数模拟小数计算的，精度只能保留到小数点后第9位(大于
0的最小值0.00000000372529)。解码精度和速度自然会有差异。因此这类手机音质
自然是不能与硬件解码相比。也很少有EQ均衡器，即便通过软件实现了，效果也不
是太好。
  
  此外流行的图像处理、3D运算、视频处理、音频处理等诸多多媒体应用都会类
似的涉及浮点运算。没有FPU单元就需要软件支持，显然牺牲了效率和质量。
  浮点运算能力是关系CPU多媒体、3D图形处理的一个重要指标。
  我们构建编译开发环境，就需要加入软浮点支持，否则涉及浮点运算就会出错。

  
四、库文件格式

  先看E680系列的库文件格式。如libjpeg.so文件，用objdump -p显示相关内容:    
  private flags = 602: [APCS-32] [VFP float format] [software FP] [has entry point]

  显然是software FP，不过使用的是VFP(Vector Float Point)矢量浮点格式。
  
  再看E600和968的库文件格式：
  private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]
  
  与E680相比，不同点在于使用的是FPA(Floating Point Arithmetic)浮点格式，
又一说为(Fixed Point Arithmetic)定点浮点运算。由于这方面知识空白，具体并
没有仔细考证。
  
  当然除此两种之外，还有一种格式
  private flags = 2 : [APCS-32] [FPA float format] [has entry point]
  这个自然是硬浮点格式了，不过如果在编译过程中加上arm-nolibfloat patch
再在gcc参数加上-msoft-float，估计也是能生成软浮点代码，不过没有亲试。

  理论上讲，不管是哪种格式，在应用程序运行链接时都是可以的，不存在兼容
性的问题，但是要做编译，库文件是必须完全一致的。

  以我手中的交叉编译工具为例，当初是构建于E680G的VFP格式，我使用夏新
E600自带的QTE库(FPA soft FP)，编译一个简单的QTE程序，出现如下错误：

  /home/gcc/toolchain/soft-arm-linux/gcc-3.3.2-glibc-2.3.2/bin/../lib/
gcc-lib/arm-linux/3.3.2/../../../../arm-linux/bin/ld: ERROR: /home/gcc/
toolchain/qt/lib/libqte-mt.so uses FPA instructions, whereas helloqt does not
  /home/gcc/toolchain/soft-arm-linux/gcc-3.3.2-glibc-2.3.2/bin/../lib/
gcc-lib/arm-linux/3.3.2/../../../../arm-linux/bin/ld: failed to merge
target specific data of file /home/gcc/toolchain/qt/lib/libqte-mt.so
collect2: ld returned 1 exit status

  这个编译环境是用cross-tool-0.28编译而成的，而且打了gcc-3.3.2的soft-
float patch，不过按patch说明，是应该可以生成FPA soft FP格式的编译环境，而
结果却是VFP soft FP，这个适用于E680系列，然不适用夏新E600和飞利浦968。

  后来我在交叉编译环境中把GCC_EXTRA_CONFIG的--with-float=soft选项去除
且把soft-float patch也同时去掉，获得的是FPA hard FP的编译环境。用这个环境
再编译夏新E600自带的QTE库(FPA soft FP)，会出现类似如下提示：

    ld uses hardware FP, whereas libqte-mt.so uses software ...
   
    我试图在gcc参数中加上-msoft-float，错误如下：
    arm-linux/bin/ld: cannot find -lfloat collect2: ld returned 1 exit status
   
    这个需要编译编译环境时加下nolibfloat的patch。
   
    如何生成FPA soft FP的格式困扰了好几天，我查看了soft-float patch本身也
搜索了大量资料，觉得可能还是patch本身的问题。我重新下载了gcc.3.4.0，使用
3.4.0 soft patch ，另外把bigendian,nolibfloat这一些有冲突的patch去掉，
果然生成了FPA soft FP格式的库文件。

  再用E600自带的QTE库，编译只是有一个告警选项：
  /home/gcc/toolchain/gcc-3.4.0-glibc-2.2.5/arm-linux/lib/gcc/arm-linux/3.4
.0/../../../../arm-linux/bin/ld: warning: libstdc++.so.5, needed by /home/gcc
/toolchain/qt-2.3.8/lib/libqte-mt.so, not found (try using -rpath or -rpath-link)

  夏新E600和飞利浦968使用的GCC版本都是3.2.1，3.4.0编译后是libstdc++.so.6，
可以查看下面的lib内容，使用的版本是不同的。

  libstdc++.so.6
  
  Version definitions:
  1 0x01 0x025f4d66 libstdc++.so.6
  2 0x00 0x08922974 GLIBCXX_3.4
  3 0x00 0x056bafd3 CXXABI_1.3
  
  Version References:
    required from libgcc_s.so.1:
      0x0b792653 0x00 10 GCC_3.3
      0x0d696910 0x00 08 GLIBC_2.0
      0x0b792650 0x00 07 GCC_3.0
    required from libm.so.6:
      0x0d696910 0x00 05 GLIBC_2.0
    required from libc.so.6:
      0x09691f73 0x00 11 GLIBC_2.1.3
      0x0d696911 0x00 09 GLIBC_2.1
      0x0d696912 0x00 06 GLIBC_2.2
      0x0d696910 0x00 04 GLIBC_2.0

  libstdc++.so.5
  
  Version definitions:
  1 0x01 0x025f4d65 libstdc++.so.5
  2 0x00 0x081a2972 GLIBCPP_3.2
  3 0x00 0x0a297d01 GLIBCPP_3.2.1
   GLIBCPP_3.2
  4 0x00 0x056bafd2 CXXABI_1.2
  
  Version References:
    required from libm.so.6:
      0x0d696910 0x00 07 GLIBC_2.0
    required from libgcc_s.so.1:
      0x0b792650 0x00 06 GCC_3.0
    required from libc.so.6:
      0x0d696912 0x00 10 GLIBC_2.2
      0x09691f73 0x00 09 GLIBC_2.1.3
      0x0d696911 0x00 08 GLIBC_2.1
      0x0d696910 0x00 05 GLIBC_2.0
     
五、总结

  E600和968编译环境问题看似是解决了，其实不然，这仅仅说明了可以生
成兼容E600,968的库文件，能否运行则是另外一回事，下文将着重说明运行时
的兼容性问题。