Linux | Tony Bai

八月 23, 2011

昨天在编译项目代码时遇到了这样一个错误：

xx_base.h:72:2: 错误：#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."

这是预编译器的错误输出。原因很明显：预编译器在处理xx_base.h时没有发现_BIG_ENDIAN或_LITTLE_ENDIAN的定义，#error预处理宏输出了如上错误。下面是出现错误位置的源码片断：

/* xx_base.h*/
#if defined(_BIG_ENDIAN)
… …
#elif defined(_LITTLE_ENDIAN)
… …
#else
#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."
#endif

xx_base.h是部门一基础库中的一个头文件，上面的做法对于基础库自身来说并无太大问题。基础库的Makefile通过检测CPU类型定义了对应的字节序宏，并在编译时作为gcc的命令行选项传入：

/* Makefile */
ifeq ($(CPU), x86)
        DEFS += -D_LITTLE_ENDIAN
else ifeq ($(CPU), sparc)
        DEFS += -D_BIG_ENDIAN
else
        $(error $(CPU) is not supported!)
endif

但是一旦这个基础库被某项目复用，且该xx_base.h文件被项目代码引用，编译就会出现问题，因为各个项目的Makefile中并没有定义_LITTLE_ENDIAN或_BIG_ENDIAN宏。如果基础库不做修改，那么复用该基础库的项目代码中就都需要考虑这两个宏的定义问题。这未免有些"强加"的意味，对于一个几乎被所有项目复用的基础库而言，这样的做法显然不妥。

那如何解决这个问题呢？一个思路是如果基础库在发布后依旧携带这些宏的定义，那就可以避免这样的问题了。在很多使用autotools(包括autoconf, automake, libtool等)协助进行代码构建的开源包中经常会看到一个名为config.h的源文件，那里面包含了与移植相关的宏定义。这个config.h是configure脚本根据config.h.in模板自动生成的。

我们的基础库如果完全用autotools改造显然也可以解决这个问题，但这样一来以前编写的一些构建脚本就要被全部抛弃，能否折中一下呢：利用autoconf生成config.h，但不输出Makefile，依旧使用原先的Makefile？

实验证明这样是可以的。只需对configure.in(或configure.ac)做一些调整即可，将类似AC_CONFIG_FILES([Makefile src/Makefile src/example/Makefile])这样的代码从configure.in中移除即可：

# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.64])
AC_INIT([baselib], [1.0.0], [xx@gmail.com])

AC_CONFIG_HEADERS([include/config.h])

# Checks for header files.
AC_CHECK_HEADERS([stddef.h stdlib.h string.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_SIZE_T

# Checks for library functions.
AC_FUNC_MALLOC
AC_CHECK_FUNCS([memset])

AC_OUTPUT

AC_CONFIG_HEADERS这句是关键！修改完configure.in后，执行autoheader，我们就会在include下发现config.h.in模板文件被生成了出来。执行autoconf生成的configure脚本后，我们在include下就得到了config.h。

下面就是在config.h中加入我们期望的宏。在我们的问题中，我们希望在configure时可以探测到当前host所用的字节序(endianess)，并将结果反映到config.h中。幸运的是autoconf内置了字节序的测试宏AC_C_BIGENDIAN。增加了AC_C_BIGENDIAN测试宏的configure.in经过autoheader处理后得到的config.h.in文件中多了如下这组代码：

/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
#endif

在Sun SPARC小机上运行configure，我们得到的config.h中有关字节序的宏定义代码如下：
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
# define WORDS_BIGENDIAN 1
# endif
#endif

config.h中定义了WORDS_BIGENDIAN宏，说明Sun Sparc小机采用的是BigEndian。这样只要基础库的头文件都在最开始包含了config.h，那么上面的问题就解决了。

不过有些朋友不喜欢WORDS_BIGENDIAN这个宏的命名，想自己给标识字节序的宏命名，比如BASELIB_IS_BIGENDIAN。那么我们如何来支持呢？这里我也找到了一个办法：

首先，就是手工编辑config.h.in(注意这之后你就不要通过autoheader生成config.h.in了)，在结尾加上这样一行：
#undef BASELIB_IS_BIGENDIAN

然后，修改configure.in，通过AC_DEFINE来定义一个新的BASELIB_IS_BIGENDIAN宏：

AC_C_BIGENDIAN
if test $ac_cv_c_bigendian = yes; then
AC_DEFINE(BASELIB_IS_BIGENDIAN, 1)
fi

我们通过AC_C_BIGENDIAN的检测结果来确定是否定义BASELIB_IS_BIGENDIAN宏，ac_cv_c_bigendian显然是AC_C_BIGENDIAN内置的一个变量，如果需要，我们也可以模仿其命名规则得到其他测试宏内置的变量。

最后，执行autoconf和configure，我们就可以在include/config.h的结尾看到这样一行定义：
#define BASELIB_IS_BIGENDIAN 1

AC_DEFINE不一定非要与测试宏绑定在一起，它的用法很灵活。如果我们的代码中需要根据不同操作系统的类型来调用不同的代码，那么我们需要在config.h中放置几个标识操作系统类型的宏，比如BASELIB_LINUX和BASELIB_SUNOS。和BASELIB_IS_BIGENDIAN一样，我们首先需要手工编辑config.h.in，增加如下两行代码：

#undef BASELIB_LINUX
#undef BASELIB_SUNOS

然后，修改configure.in，加入自定义的OS测试代码，并且定义对应的宏：

os=`uname -s`
case $os in
    Linux)
        AC_DEFINE(BASELIB_LINUX, 1)
        ;;
    SunOS)
        AC_DEFINE(BASELIB_SUNOS, 1)
        ;;
    *)
        AC_ERROR([host is unsupported.])
        ;;
esac

最后，执行autoconf和configure。如果我们在redhat上，我们就会在config.h中看到如下代码：

#define BASELIB_LINUX 1
/* #undef BASELIB_SUNOS */

autoconf也内置了一系列系统类型测试宏，比如AC_CANONICAL_SYSTEM(依赖install-sh、config.sub和config.guess三个脚本)，其测试后的结果放在了$host变量中，你也可以通过判断$host变量来确定到底在config.h中定义哪个宏。

偿还N年前的一笔技术债

七月 21, 2011

0 条评论

记得刚来公司时曾参与过一个项目，项目中用到了部门基础库中的一个B+树接口。不过在程序调试过程中我们发现可执行程序总是dump core（在sparc solaris上），经初步分析，断定问题就出在B+树接口处，但一时又找不到问题原因。还好这个B+树的实现者就坐在我的旁边。他分析后告诉我：这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍。按照他的说法，我为结构体打了padding，以满足结构体size为4的整数倍的要求。修改后果然不再dump core了。当时项目进度紧，我也没有求甚解，这件事也就过去了。

一晃N年过去了。今天在做程序的64位移植过程中我再次遇到了这个问题。问题的表象就是程序运行时dump core，通过gdb或pstack查看core的内容，发现程序是在B+ Tree初始化时出的core。显然这又是一个内存违规访问的问题，且在Sparc上出现（x86 Linux上运行正常）十有八九与内存对齐有关。

B+ Tree出问题首先让我想到了N年前的那个解决方法。我先查看了自定义的索引结构体(usr_idx)：

struct usr_idx {
unsigned int usr;
};

不过sizeof(usr_idx)无论是32bit编译还是64bit编译，其值都是4。那按照B+树原作者的说法，这显然不足以让B+树出现问题。事实也的确如此，32bit编译的程序在Sparc Solaris下运行良好，只是目前改为了64bit编译，才dump core，那问题到底出现在哪呢？

到这里，我也只能从代码着手了，把N年前没弄清楚的原因找出来，顺便也把这个存在了N年的Bug彻底解决掉，把这笔技术债还了。pstack的输出告诉我问题出在一个名为bptree_create_node的函数中，嫌疑最大的一处代码大致是这样的：

for (i = 0; i rank; i++) {
(elem_base(tree, tmp_bn, i))->key = key_base(tree, tmp_bn, i);
(elem_base(tree, tmp_bn, i))->pointer = NULL;
}

直觉告诉我问题出在elem_base这个宏里，elem_base的定义如下：

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

很显然这个定义最终是想得到一个xx_bptree_elem*类型的指针。从内存地址角度来说，我们会得到了一个内存地址，且这个地址被认为是一个xx_bptree_element元素的起始地址。那么是否所有地址作为xx_bptree_element元素的起始地址都合法呢？答案是不一定，至少在Sparc平台上不是所有地址都可以作为xx_bptree_elem的起始地址的。

那么什么样地址可以作为xx_bptree_element的起始地址呢？在Sparc上这取决于结构体的对齐系数。xx_bptree_elem结构的定义如下：

union mem_word {
    void *mw_vp;
    void (*mw_fp)(void);
    char *mw_cp;
    long   mw_l;
    double mw_d;
};
typedef union mem_word mem_word;
#define SIZEOF_mem_word (sizeof(mem_word))

struct xx_bptree_elem {
    void       *key;
    void       *pointer;
    mem_word   base;
};
typedef struct xx_bptree_item xx_bptree_item;
#define SIZEOF_bptree_elem        (sizeof(xx_bptree_elem)-sizeof(mem_word))

在32bit编译的情况下，系统默认对齐系数为4(参见/usr/include/sys/isa_defs.h中的宏_MAX_ALIGNMENT)，则该结构体的对齐系数 = min(max(sizeof(key), sizeof(pointer), sizeof(base)), 4) = 4。这样xx_bptree_elem在32bit下的有效起始地址为可被4整除的内存地址。

而在用64bit编译时，系统默认的对齐系数为16（同参见isa_defs.h），但由于xx_bptree_elem中size最大的字段(base)的size为8，则结构体的对齐系数就等于8。即xx_bptree_elem元素的有效起始地址为可被8整除的地址。

好了，我们再回过头来看看elem_base宏在不同编译情况下能否总是返回合法的地址。

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

这个宏中有三个元素决定返回地址，分别是"基址"：&(eb)->e_base.mw_cp、偏移量SIZEOF_bptree_elem和(tree)->keysize。其中基址是另外一个结构体xx_bptree_node中一个mem_word类型字段的地址，你知道的，mem_word这种手法可以保证其起始地址严格按照其内部最大字段的对齐系数对齐的，也就是说mem_word的对齐系数与double的对齐系数一致，即无论是32bit编译还是64bit编译，其对齐系数都是8，也就是说我们可以确保这个”基址“是可以被8整除的；至于偏移量SIZEOF_bptree_elem，我们可以直接可以得出其大小：

32bit下，SIZEOF_bptree_elem = 8
64bit下，SIZEOF_bptree_elem = 16

可以看出无论是32bit还是64bit编译，SIZEOF_bptree_elem的值都是8的倍数；显然这两个值都不会影响elem_base最终返回地址的合法性。

现在剩下的就是(tree)->keysize了。keysize是由xx_bptree_init接口传进来的，它在上层实际上就是用户自定义的索引结构体的大小，显然这个大小不一定就是8的倍数。在我们的系统中，keysize = sizeof(usr_idx) =
4。这个keysize在32bit编译下是没有问题的，因为32bit编译只需要elem_base返回的地址可以被4整除即可，这也是为什么我们的程序在32bit编译下运行正常的原因。回想一下N年前的那个问题，其真正原因也就在这里：当时我定义的索引结构体的大小无法被4整除。在64bit编译下，keysize显然不能满足被8整除的要求，导致elem_base返回的地址只能被4整除。而xx_bptree_elem这个结构体的地址是严格要求必须可被8整除的。将一个只能被4整除而不能被8整除的地址强制转换为xx_bptree_elem元素地址并通过该强制类型转换后的地址访问xx_bptree_elem内部的元素显然就会导致core的出现了。

现在看来当初我的同事并未真正理解该B+ tree为何要求用户自定义结构体的大小必须为4的整数倍了，他只是通过现象得到了那条经验罢了，这笔技术债务也就从那时留了下来。

解决该问题并不难，作为基础库，我们无论如何都不应该依赖用户的自觉，我们在接口实现中增加一个转换就可以解决这一隐藏了若干年的Bug，将外面传入的keysize经align_word转换后再赋给tree->keysize，这样就可以保证elem_base始终返回合法的地址了。

突然想起了那句话：”出来混，总是要还的“，我们欠的技术债务也不例外。