标签：gcc

Linux kernel 笔记 （62）——list_head

双向链表是Linux kernel中常用的数据结构，定义如下：

struct list_head {
    struct list_head *next, *prev;
};

#define LIST_HEAD_INIT(name) { &(name), &(name) }

#define LIST_HEAD(name) \
    struct list_head name = LIST_HEAD_INIT(name)

static inline void INIT_LIST_HEAD(struct list_head *list)
{
    list->next = list;
    list->prev = list;
}
...

下图选自plka：

Capture

从上图可以看出，定义链表需要一个头结点，通过头结点继而可以完成插入，删除元素等操作。来看一个例子（list.c）：

struct list_head {
        struct list_head *next, *prev;
};

#define LIST_HEAD_INIT(name) { &(name), &(name) }

#define LIST_HEAD(name) \
        struct list_head name = LIST_HEAD_INIT(name)


int main(void) {
        LIST_HEAD(dev_list);
        return 0;
}

检查gcc预处理的输出：

# gcc -E -P list.c
struct list_head {
 struct list_head *next, *prev;
};
int main(void) {
 struct list_head dev_list = { &(dev_list), &(dev_list) };
 return 0;
}

可以看到，头结点dev_list的prev和next都指向了自己。下面代码达到同样的效果：

struct list_head {
    struct list_head *next, *prev;
};

static inline void INIT_LIST_HEAD(struct list_head *list)
{
    list->next = list;
    list->prev = list;
}

int main(void) {
    struct list_head dev_list;
    INIT_LIST_HEAD(&dev_list);
    return 0;
}

 

解决编译错误“fatal error: ‘libelf.h’ file not found”

原文发布于hellogcc网站。

最近在编译一个开源项目时，遇到这个编译错误：

fatal error: 'libelf.h' file not found
#include <libelf.h>
     ^
1 error generated.

解决方法是安装elfutils-libelf-devel这个软件包：

yum install elfutils-libelf-devel

或：

dnf install elfutils-libelf-devel

在VirtualBox上安装Solaris 11

为了更方便地研究DTrace，花了一下午时间装了个Solaris 11的虚拟机。基本就是靠着google，解决了所有问题。在这里简单列举一下步骤，希望可以帮到有需求的朋友：

（1）在VirtualBox上安装Solaris 11，基本可以参考这篇文章;
（2）由于VirtualBox不支持滚动条，所以我习惯于用ssh客户端登陆上去进行操作。而Solaris默认不支持root用户直接ssh登陆。修改方法参照这篇文章；
（3）Solaris 11安装包默认没有gcc，可参考stackoverflow这篇帖子下载安装gcc。期间如果涉及到如何配置Solaris 11的DNS服务，可参考这篇帖子。

一键编译安装gcc

本文原载于我在hellogcc上的文章。

今天看到一篇文章，作者通过一个shell脚本和一个Makefile，可以自动下载需要的所有安装包并且自动编译gcc：

$ # Download the scripts using wget.
$ mkdir /opt/gcc-4.9.2
$ cd /opt/gcc-4.9.2
$ wget http://projects.joelinoff.com/gcc-4.9.2/bld.sh
$ wget http://projects.joelinoff.com/gcc-4.9.2/Makefile
$ chmod a+x bld.sh
$ make
[output snipped]
$ # The compiler is installed in /opt/gcc-4.9.2/rtf/bin

我试了一下，果然很方便。只要有一台可以联网的机器，就可以了。感兴趣的朋友可以试一试。

P.S.：
（1）编译libiconv时可能会有“'gets' undeclared here“错误，请参考这篇文章。
（2）如果机器是64位的，但是缺少32位的库文件。这样在编译gcc时会出现错误：“configure: error: I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.”。提示需要配置“--disable-multilib”。

在RedHat上快速安装gcc

今天需要在一台干净的RedHat上快速安装gcc，好能编译一些lib库。登录https://idp.redhat.com/idp/，下载了能找到的最高版本的安装包：cpp-3.2.3-60.x86_64.rpm和gcc-3.2.3-60.x86_64.rpm，安装一气呵成：

[root@localhost nan]# rpm -ivh cpp-3.2.3-60.x86_64.rpm
warning: cpp-3.2.3-60.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID db42a60e: NOKEY
Preparing...            ########################################### [100%]
   1:cpp                ########################################### [100%]
[root@localhost nan]# rpm -ivh gcc-3.2.3-60.x86_64.rpm 
warning: gcc-3.2.3-60.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID db42a60e: NOKEY
Preparing...            ########################################### [100%]
   1:gcc                ########################################### [100%]

验证一下：

[root@localhost nan]# gcc -v
Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-60)

尽管版本有点低，最起码现在有个能用的gcc了。如果需要高版本，再用这个gcc编译吧。

gcc的 “-fpack-struct” 编译选项导致程序core dump的分析

最近team引入gcov来做代码分析。编译好的程序在Solaris上运行的好好的，结果在Linux上一运行就会产生core dump文件。这篇文章就介绍整个分析过程。

首先用gdb分析core文件,显示是strlen调用出了问题：

(gdb) bt
#0  0x00000034e433386f in __strlen_sse42 () from /lib64/libc.so.6
#1  0x000000000053c57a in __gcov_init ()
#2  0x000000000053c4b9 in _GLOBAL__I_65535_0_g_cmd_param () at source/rerun/aicent_ara_rerun.c:963
#3  0x000000000053dc26 in __do_global_ctors_aux ()
#4  0x0000000000403743 in _init ()
#5  0x00007fff6d6b3ce8 in ?? ()
#6  0x000000000053db55 in __libc_csu_init ()
#7  0x00000034e421ecb0 in __libc_start_main () from /lib64/libc.so.6
#8  0x0000000000404449 in _start ()

由于我们使用的gcc是用安装包形式安装的，没有源码。所以就从github上找了相应版本的gcc源代码，希望能有所帮助。以下是__gcov_init函数的代码（https://github.com/gcc-mirror/gcc/blob/gcc-4_4_7-release/gcc/libgcov.c）：

void
__gcov_init (struct gcov_info *info)
{
  if (!info->version)
    return;
  if (gcov_version (info, info->version, 0))
    {
      const char *ptr = info->filename;
      gcov_unsigned_t crc32 = gcov_crc32;
      size_t filename_length =  strlen(info->filename);

      /* Refresh the longest file name information */
      if (filename_length > gcov_max_filename)
        gcov_max_filename = filename_length;

      do
    {
      unsigned ix;
      gcov_unsigned_t value = *ptr << 24;

      for (ix = 8; ix--; value <<= 1)
        {
          gcov_unsigned_t feedback;

          feedback = (value ^ crc32) & 0x80000000 ? 0x04c11db7 : 0;
          crc32 <<= 1;
          crc32 ^= feedback;
        }
    }
      while (*ptr++);

      gcov_crc32 = crc32;

      if (!gcov_list)
    atexit (gcov_exit);

      info->next = gcov_list;
      gcov_list = info;
    }
  info->version = 0;
}

结合源代码和core文件可以看出，应该是“size_t filename_length = strlen(info->filename);”这一行出了问题。再结合汇编程序：

(gdb) disassemble __strlen_sse42
Dump of assembler code for function __strlen_sse42:
   0x00000034e4333860 <+0>:     pxor   %xmm1,%xmm1
   0x00000034e4333864 <+4>:     mov    %edi,%ecx
   0x00000034e4333866 <+6>:     mov    %rdi,%r8
   0x00000034e4333869 <+9>:     and    $0xfffffffffffffff0,%rdi
   0x00000034e433386d <+13>:    xor    %edi,%ecx
=> 0x00000034e433386f <+15>:    pcmpeqb (%rdi),%xmm1

是访问rdi寄存器出了问题，而rdi保存的应该是strlen的参数，也就是“info->filename”。试着访问一下rdi寄存器保存的地址：

(gdb) i registers rdi
rdi            0x57c4ac00000000 24704565987246080
(gdb) x/16xb 0x57c4ac00000000
0x57c4ac00000000:       Cannot access memory at address 0x57c4ac00000000

可以看到rdi寄存器保存的地址的确是个无效的地址。

接下来，就要分析一下为什么传入__gcov_init的info结构体的filename是一个无效指针。首先看一下gcov_info结构体的定义（https://github.com/gcc-mirror/gcc/blob/gcc-4_4_7-release/gcc/gcov-io.h）：

/* Information about a single object file.  */
struct gcov_info
{
  gcov_unsigned_t version;  /* expected version number */
  struct gcov_info *next;   /* link to next, used by libgcov */

  gcov_unsigned_t stamp;    /* uniquifying time stamp */
  const char *filename;     /* output file name */

  unsigned n_functions;     /* number of functions */
  const struct gcov_fn_info *functions; /* table of functions */

  unsigned ctr_mask;        /* mask of counters instrumented.  */
  struct gcov_ctr_info counts[0]; /* count data. The number of bits
                     set in the ctr_mask field
                     determines how big this array
                     is.  */
};

查看调用__gcov_init的_GLOBAL__I_65535_0_g_cmd_param函数的汇编代码：

(gdb) disassemble _GLOBAL__I_65535_0_g_cmd_param
Dump of assembler code for function _GLOBAL__I_65535_0_g_cmd_param:
   0x000000000053c4ab <+0>:     push   %rbp
   0x000000000053c4ac <+1>:     mov    %rsp,%rbp
   0x000000000053c4af <+4>:     mov    $0x78d4a0,%edi
   0x000000000053c4b4 <+9>:     callq  0x53c4c0 <__gcov_init>
   0x000000000053c4b9 <+14>:    leaveq
   0x000000000053c4ba <+15>:    retq
End of assembler dump.

可以看到传入__gcov_init的参数为0x78d4a0，也就是指向gcov_info结构体的地址，查看这个地址的内容：

(gdb) x/64xb 0x78d4a0
0x78d4a0:       0x52    0x34    0x30    0x34    0x00    0x00    0x00    0x00
0x78d4a8:       0x00    0x00    0x00    0x00    0x82    0xf0    0xc7    0xa5
0x78d4b0:       0x60    0xc4    0x57    0x00    0x00    0x00    0x00    0x00
0x78d4b8:       0x0b    0x00    0x00    0x00    0xac    0xc4    0x57    0x00
0x78d4c0:       0x00    0x00    0x00    0x00    0x01    0x00    0x00    0x00
0x78d4c8:       0x39    0x01    0x00    0x00    0xc0    0xa4    0x47    0x03
0x78d4d0:       0x00    0x00    0x00    0x00    0xe0    0xd8    0x53    0x00
0x78d4d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00

可以看到对应filename成员的值应该为0x57c4ac0000000b，的确是个无效地址。问题分析到这里，没了思路。后来，在gcc的bugzilla里找到这个问题：https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43341，才搞清楚是“-fpack-struct=4”这个编译选项导致的。

我们使用的是64位Linux，默认编译生成的可执行文件是64位的。所以gcov_info的默认内存布局应该是（gcov_unsigned_t类型占4个字节，指针类型占8个字节）：

Offset 4 bytes 4 bytes
0 version 填充成员
8 next next
16 stamp 填充成员
24 filename filename
… … …

当使用“-fpack-struct=4”这个编译选项后，gcov_info的内存布局变为：

Offset 4 bytes 4 bytes
0 version next
8 next stamp
16 filename filename
… … …

经过推算，filename成员的值应该为0x57c460，验证一下：

(gdb) p (char*)0x57c460
$1 = 0x57c460 "/home/.../.....gcda"

打印出的是正确的值。在Solaris上没问题的原因是因为64位Solaris默认编译出来的程序是32位的。

看了一下gcc网站对-fpack-struct的介绍（https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fpack-struct-2675），使用这个编译选项会导致ABI(Application Binary Interface)的改变，所以使用时一定要谨慎。

本文转载自我在hellogcc上文章：http://www.hellogcc.org/?p=34087。

关于“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位，看用户自己的选择了。

分享几篇关于gcc和gdb的文章

海法Linux俱乐部是一群在以色列海法地区生活的Linux工程师定期组织的，分享在Linux下开发程序经验的聚会。网站是http://www.haifux.org/。其中有很多topic，涉及的范围很广，感兴趣的同学可以登陆这个网站看一下。我把其中和gcc和gdb相关的文章选出来，分享在下面：
gdb – customize it the way you want；
Advanced GDB；
Compiling Effectively for Cell with GCC；
GCC Profile Guided Optimization。

Solaris搭建64位C语言开发环境

刚来公司时，公司的C程序还是32位的。后来我阅读了一些资料，觉得64位的程序才是真正的趋势，所以就开始尝试着开发64位的程序。这篇文章介绍如何在Solaris下搭建64位C语言开发环境，希望给需要的朋友一点帮助。

（1）gcc

Solaris的/usr/sfw/bin/gcc可以用来编译64位C程序，但是需要加-m64编译选项，否则默认编译出来的是32位程序。此外也可以从gcc的官网下载gcc源代码，自行编译安装，但是要注意编译出来的gcc需要是64位的。

（2）gdb

调试64位C程序需要64位的gdb，gdb的安装步骤如下（以7.6版本为例）：

1）gunzip gdb-7.6.tar.gz
2）tar xvf gdb-7.6.tar
3）export CC=”/usr/sfw/bin/gcc -m64″
4）mkdir build_gdb
5）cd build_gdb
6）../gdb-7.6/configure –prefix=“/…/…(a folder path)”
7）make
8）make install

需要注意以下两点：

a）Solaris下的tar程序不支持”-z”选项，所以只能先调用gunzip，再调用tar，不能一步搞定：tar -xzf gdb-7.6.tar.gz。

b）目前gdb的最新版本是7.7，在Solaris下编译会有错误。解决办法也很简单，可以参考这篇文章。

（3）参考资料

个人认为Oracle的这本《Solaris 64-bit Developer’s Guide》，是在Solaris下开发64位C程序最好的资料。每一位C语言开发者都应该看一下，相信都能受益匪浅。