Gcc on ZRJ | 学习笔记

动态链接库中的全局变量

Thu, 26 Mar 2015 14:56:46 +0800

想给自己之前的日志库，加一个染色的功能

gcc 有一个自己的特性，叫 __thread，介绍可以看这里，https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Thread_002dLocal.html，是可以用来修饰一个全局变量，从而让这个全局变量在每个线程都有一份拷贝，例子如下：

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include <sys/syscall.h>

__thread int n = 0;

int ns[] = {1, 2};

void* thread_func(void *arg) {
    int tid = (int)syscall(__NR_gettid);
    printf("1, tid = %d, n = %d\n", tid, n);
    n = *((int*)arg);
    printf("2, tid = %d, n = %d\n", tid, n);
    while (1) {
        printf("3, tid = %d, n = %d\n", tid, n);
        sleep(1);
    }
}

int main() {
    for (int i = 0; i < sizeof(ns)/sizeof(ns[0]); i++) {        
        pthread_t tid;
        pthread_create(&tid, NULL, thread_func, &ns[i]);
        printf("thread %d created\n", tid);
    }
    while (1) {
        sleep(1);
    }
    return 0;
}

跑起来之后的输出是这样的

thread 1082132800 created
thread 1090525504 created
1, tid = 11508, n = 0
2, tid = 11508, n = 1
3, tid = 11508, n = 1
1, tid = 11509, n = 0
2, tid = 11509, n = 2
3, tid = 11509, n = 2
3, tid = 11508, n = 1
3, tid = 11509, n = 2
3, tid = 11508, n = 1
3, tid = 11509, n = 2
3, tid = 11508, n = 1
3, tid = 11509, n = 2

用在日志库中，成为这个样子

#include <net/if.h>
#include <arpa/inet.h>
#include "logger.h"

__thread int m_iLoggerLogTraceOn;// 是否开启染色日志

int Logger::Init(eLogLevel level, const char* pLogFileDir, const char* pLogFileBaseName, uint32_t uiLogFileRollingSize, uint32_t uiMaxCharPerLine, uint32_t uiLogBufferLines)
{
    pthread_mutex_lock(&m_stInitLock);
    if (m_bInited || level == LOG_LEVEL_OFF)
    {
        pthread_mutex_unlock(&m_stInitLock);
        return 0;
    }

然后加了一个修改的接口

void Logger::setLogTraceOn(int iTraceOn)
{
    printf("set trace switch to %d\n", iTraceOn);
    m_iLoggerLogTraceOn = iTraceOn;
    printf("after set, iLoggerLogTraceOn(%p) is %d, tid is %d\n", &m_iLoggerLogTraceOn, m_iLoggerLogTraceOn, (int)syscall(__NR_gettid));
}

在各个函数处也加了跟踪

void Logger::LogToMem(eLogLevel level, const char* format, ...)
{
    printf("trace on(%p) : %d, tid is %d\n", &m_iLoggerLogTraceOn, m_iLoggerLogTraceOn, (int)syscall(__NR_gettid));
    if (m_bInited && (level >= m_eLevel || m_iLoggerLogTraceOn))
    {
        va_list args;
        va_start(args, format);            
        char *pWritePtr = m_pLogBufferMem+((__sync_add_and_fetch(&m_uiWriteLineCount, 1) % m_uiLogBufferLines) * m_uiMaxCharPerLine);
        vsnprintf(pWritePtr+1, m_uiMaxCharPerLine-2, format, args); 
        *(pWritePtr) = 1;
        va_end(args);
    }        
}

void Logger::LogToStdout(eLogLevel level, const char* format, ...)
{    
    printf("trace on(%p) : %d, tid is %d\n", &m_iLoggerLogTraceOn, m_iLoggerLogTraceOn, (int)syscall(__NR_gettid));
    if (m_bInited && (level >= m_eLevel || m_iLoggerLogTraceOn))
    {
        va_list args;
        va_start(args, format);
        vprintf(format, args);
        va_end(args);
    }        
}

然后在业务中这么使用

if (pSession->strAppUser == "BAAEB881F489FC59")
    {
        Logger::setLogTraceOn(1);
        LOG_INFO("appuser match, turn logger trace on");
    }

然而，跑起来之后是这样的

set trace switch to 1
after set, iLoggerLogTraceOn(0x797bf0) is 1, tid is 9696
[2015-03-26 14:28:20] [INFO][            OnRequestData@          src/BusiObj.cpp,0136]  appuser match, turn logger trace on
trace on(0x43b0693c) : 0, tid is 9696
trace on(0x43b0693c) : 0, tid is 9696
trace on(0x43b0693c) : 0, tid is 9696
trace on(0x43b0693c) : 0, tid is 9696
trace on(0x43b0693c) : 0, tid is 9696

注意到一个神奇的现象，同一个变量，在同一个线程里面，指针不一样了

考虑到之前做函数耗时测试，和代码覆盖度测试的时候，遇到过由于进程关系复杂（又多进程又线程的）引起的问题，考虑是否由于这个原因引起的问题，于是写了这么一个测试

来看这个：

t2.cpp

#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>

__thread int n = 0;

extern "C" {
    void busi(int arg) {    
        printf("1, tid = %d, n = %d\n", (int)syscall(__NR_gettid), n);
        n = arg;
        printf("2, tid = %d, n = %d\n", (int)syscall(__NR_gettid), n);
        while (1) {
            printf("3, tid = %d, n = %d\n", (int)syscall(__NR_gettid), n);
            sleep(1);
        }
    }
}

f1.cpp

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <pthread.h>
#include <unistd.h>

int ns[] = {1, 2};

typedef void(*busi_func_ptr_t)(int);
busi_func_ptr_t busi_func_ptr ;

void* thread_func(void *args) {
   int arg = *((int*)args); 
   printf("0, arg = %d\n", arg);
   (*busi_func_ptr)(arg);
}

int main() {    
    int fork_ret = fork();
    if (fork_ret == 0) {
        void* dll = dlopen("./t2.so", RTLD_LAZY);
        if (dll == NULL) {
            printf("%s\n", dlerror());
            abort();
        }
        busi_func_ptr = (busi_func_ptr_t)dlsym(dll, "busi");
        char *err = dlerror();
        if (err != NULL) {
            printf("%s\n", err);
            abort();
        }
        for (int i = 0; i < sizeof(ns)/sizeof(ns[0]); i++) {
            pthread_t tid;
            pthread_create(&tid, NULL, thread_func, &ns[i]);
            printf("thread %d created\n", tid);
        }
        while (1) {
            sleep(1);
        }
        dlclose(dll);
    } else {
        printf("chid proc %d\n", fork_ret);
        while (1) {
            sleep(1);
        }
    }
    return 0;
}

makefile

all:
	g++ t2.cpp -O3 -shared -o t2.so -fPIC
	g++ f1.cpp -O3 -o f1 -ldl -pthread

makefile 带 O3 是为了跟实际情况保持一致

运行输出如下

thread 1082132800 created
chid proc 12856
thread 1090525504 created
0, arg = 1
1, tid = 12857, n = 0
2, tid = 12857, n = 1
3, tid = 12857, n = 1
0, arg = 2
1, tid = 12858, n = 0
2, tid = 12858, n = 2
3, tid = 12858, n = 2
3, tid = 12857, n = 1
3, tid = 12858, n = 2
3, tid = 12857, n = 1
3, tid = 12858, n = 2

看起来是没有问题的，又考虑到，我们的日志是先编译成一个静态的 lib.a 的库，然后在编译到 lib.so 的动态库中，最后由框架加载运行的，于是试了一下这么搞

我写了一个 test.cpp

public:

	//与tcpd的接口
	char * OnRequestData(const char * p_pcResData,
		                 int p_iResDataLen,
		                 int& p_iRetDataLen,
		                 int& p_iDataBufLen, 
		                 const char *p_pcHostIP, 
		                 const char * p_pcBusiBuf,
		                 int& piProcessedDataLen, int fd)
    {
        Logger::setLogTraceOn(1);
        printf("on request123\n");
        LOG_DEBUG("on request123");
        LOG_ERR("on request123");
        Logger::setLogTraceOn(0);
        printf("on request456\n");
        LOG_DEBUG("on request456");
        LOG_ERR("on request456");
        Logger::setLogTraceOn(1);
        printf("on request789\n");
        LOG_DEBUG("on request789");
        LOG_ERR("on request789");
        Logger::setLogTraceOn(0);
        return NULL;
    }
	
	int    OnDllDataUpdate(const char * p_pcDataBuf, int p_iDataBufLen) {}
	bool   FreeMemBlock(char * p_pcMemBlock, int p_iMemBlockLen) {
        return true;
    }
	bool   InitDllWithCfgFile(const char *p_pcCfgFileName) {
        printf("%s\n", p_pcCfgFileName);
        Logger::Init(Logger::LOG_LEVEL_INFO, "./", "stdout");
        Logger::setLogTraceOn(1);
    }

然后把含有日志库的通用组件的静态库和这个 test.cpp 放在同一个目录中，编出一个动态库

g++ test.cpp libcommontool.a -shared -o lib.so -fPIC

然后用 tcpd 去加载这个动态库

这个是 Init 函数打出来的

CALL DLL INIT INTERFACE
./main.cfg
set trace switch to 1
after set, iLoggerLogTraceOn(0x51be60) is 1, tid is 15719

这个是 OnRquest 函数打出来的

set trace switch to 1
after set, iLoggerLogTraceOn(0x52f280) is 1, tid is 15721
on request123
trace on(0x4090193c) : 0, tid is 15721
trace on(0x4090193c) : 0, tid is 15721
[2015-03-26 14:49:15][ERROR][            OnRequestData@                 test.cpp,0026]  on request123
set trace switch to 0
after set, iLoggerLogTraceOn(0x52f280) is 0, tid is 15721
on request456
trace on(0x4090193c) : 0, tid is 15721
trace on(0x4090193c) : 0, tid is 15721
[2015-03-26 14:49:15][ERROR][            OnRequestData@                 test.cpp,0030]  on request456
set trace switch to 1
after set, iLoggerLogTraceOn(0x52f280) is 1, tid is 15721
on request789
trace on(0x4090193c) : 0, tid is 15721
trace on(0x4090193c) : 0, tid is 15721
[2015-03-26 14:49:15][ERROR][            OnRequestData@                 test.cpp,0034]  on request789
set trace switch to 0
after set, iLoggerLogTraceOn(0x52f280) is 0, tid is 15721

于是到此就陷入了僵局，查资料说 gcc 在编译动态链接库的时候对全局变量的处理有一些特殊，看到这里，http://blog.csdn.net/zxh821112/article/details/8969541，还有，http://blog.csdn.net/yuyin86/article/details/10239479，http://bbs.chinaunix.net/thread-1620536-1-1.html，和这里，https://www.owent.net/2014/01/cpp%E5%8F%88%E4%B8%80%E5%9D%91-%E5%8A%A8%E6%80%81%E9%93%BE%E6%8E%A5%E5%BA%93%E4%B8%AD%E7%9A%84%E5%85%A8%E5%B1%80%E5%8F%98%E9%87%8F.html，不过这些帖子在讨论，主要是集中在一个动态库被多个进程引用的时候的赋值问题，跟我们这个场景还不太一样

-—————–

2015-3-26 20:34:46 update http://lists.freebsd.org/pipermail/freebsd-hackers/2007-March/020057.html 这里有一篇，之前没发现

-——————–

2015-3-27 11:33:43 update 最后确认是编译器的问题，生产环境的编译器是 4.1.2 的老古董，换一个 gcc 4.8.2 问题就烟消云散了

gcc 链接时动态库和静态库的优先选择

Fri, 14 Mar 2014 20:10:56 +0800

老话题了，不过还是记一笔

先看文件

ModuleA.cpp

int add(int a, int b)
{
    return a + b;
}

ModuleB.cpp

int minus(int a, int b)
{
    return a - b;
}

Main.cpp

#include <stdio.h>

int add(int, int);
int minus(int , int);

int main()
{
    printf("%d\n", add(1, 2));
    printf("%d\n", minus(2, 1));
    return 0;
}

Makefile

all:
	g++ -c -fPIC Main.cpp
	g++ -c -fPIC ModuleA.cpp
	g++ -c -fPIC ModuleB.cpp
	g++ -shared ModuleA.o ModuleB.o -o libmodule.so
	g++ -o Run Main.o -L./ -lmodule
clean:
	rm *.o *.so Run

记得指定动态库路径

$ export LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH

ldd 确认一下

$ ldd Run 
/$LIB/libonion.so => /lib64/libonion.so (0x00002b98dea29000)
libmodule.so => ./libmodule.so (0x00002b98deb39000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b98dec4d000)
libm.so.6 => /lib64/libm.so.6 (0x00002b98dee4c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b98defa1000)
libc.so.6 => /lib64/libc.so.6 (0x00002b98df0ae000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b98df2ef000)
/lib64/ld-linux-x86-64.so.2 (0x00002b98de90d000)

跑起来

$ ./Run 
3
1

再来看静态的方式，修改后的 Makefile

all:
	g++ -c -fPIC Main.cpp
	g++ -c -fPIC ModuleA.cpp
	g++ -c -fPIC ModuleB.cpp
	ar -r libmodule.a ModuleA.o ModuleB.o
	g++ -o Run Main.o -L./ -lmodule
clean:
	rm *.o *.a Run

编译出来的已经不依赖动态库了（废话）

$ ldd Run 
/$LIB/libonion.so => /lib64/libonion.so (0x00002ad9ce948000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ad9cea58000)
libm.so.6 => /lib64/libm.so.6 (0x00002ad9cec56000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ad9cedac000)
libc.so.6 => /lib64/libc.so.6 (0x00002ad9ceeb9000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ad9cf0f9000)
/lib64/ld-linux-x86-64.so.2 (0x00002ad9ce82c000)

静态版本的 Run 是 9850 字节，动态是 9954 字节，这。。

下面问题来了，如果静态动态都有，链接器要哪个呢

all:
	g++ -c -fPIC Main.cpp
	g++ -c -fPIC ModuleA.cpp
	g++ -c -fPIC ModuleB.cpp
	ar -r libmodule.a ModuleA.o ModuleB.o
	g++ -shared ModuleA.o ModuleB.o -o libmodule.so
	g++ -o Run Main.o -L./ -lmodule
clean:
	rm *.o *.a *.so Run

答案是动态库

$ ldd Run 
/$LIB/libonion.so => /lib64/libonion.so (0x00002b2243070000)
libmodule.so => ./libmodule.so (0x00002b2243180000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b2243294000)
libm.so.6 => /lib64/libm.so.6 (0x00002b2243493000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b22435e8000)
libc.so.6 => /lib64/libc.so.6 (0x00002b22436f5000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b2243936000)
/lib64/ld-linux-x86-64.so.2 (0x00002b2242f54000)

可以这样来强制链接静态库

all:
	g++ -c -fPIC Main.cpp
	g++ -c -fPIC ModuleA.cpp
	g++ -c -fPIC ModuleB.cpp
	ar -r libmodule.a ModuleA.o ModuleB.o
	g++ -shared ModuleA.o ModuleB.o -o libmodule.so
	g++ -o Run Main.o libmodule.a
clean:
	rm *.o *.a *.so Run

历史评论

Joanie Lucien (2018-06-07 20:57:09):

Nice bro!

分支预测以及 gcc 的 __builtin_expect

Mon, 10 Feb 2014 16:26:42 +0800

在阅读代码的时候，发现有类似这种写法：

bvl = bvec_alloc(gfp_mask, nr_iovecs, &idx);
if (unlikely(!bvl)) {
  mempool_free(bio, bio_pool);
  bio = NULL;
  goto out;
}

注意到第二行，if 的判断中，加入了一个 unlikely，这个东西是一个 CPU 指令的优化，用于分支预判，关于分支预判，可以看这个 stackoverflow 的经典问答，http://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array，简单的说，就是 CPU 由于指令流水，需要在上一个条件判断的指令尚未得到结果的时候，从代码段中预读下一个指令，这个时候，会使用一个分支预测的东西，猜一个分支，然后把指令先读出来

举例说明：假如我们有如下的代码：

if (do_judge())
{
    func_a();
}
else
{
    func_b();
}

CPU 一边读取指令，一边执行指令，同时进行，那么当指令的执行模块在跑 do_judge() 这个判断的时候，读取的模块怎么办呢，一种方法是停下来，等 do_judge() 跑完，知道结果了，再根据 true or false 去读取对应分支下面的代码指令，但是这样就要干等，会浪费好几个 CPU 时钟周期，另外一种方式，就是猜，我先猜一个结果，反正不是 true 就是 false 嘛，猜一个然后先把对应的指令读出来，准备好给执行模块用。显然，如果猜中了，那么皆大欢喜，CPU 可以继续高速运转，如果不幸猜错了，那么就悲剧了，需要刚刚的这几步全部退回去重来，重新去读取另外一个分支下面的代码。自然效率就会大打折扣了。

回到之前的 likely，这个东西其实是一个宏定义，定义如下

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

__builtin_expect 是一个 gcc 的内置函数，那么这个写法的用意就很好理解了，程序员根据经验，显式的指明当前 if 分支一般情况下是否会成立，好加大 CPU 分支预测的成功率，加快代码的执行效率，不过，另外我们注意到，定义中有这个写法

!!(x)

这种两次取反的写法，作用是把非零的值，全部转到 1 上面去，也就说 0 两次取反后还是 0，而其他的非零值，包括大于 1 的整形，布尔型，等等，都会转成 1，好跟 __builtin_expect 后面的第二个参数比较。更多资料，可以进一步阅读，http://kernelnewbies.org/FAQ/LikelyUnlikely，http://stackoverflow.com/questions/2527086/what-does-x-mean-in-c-esp-the-linux-kernel

函数返回对象时的问题

Fri, 24 Jan 2014 18:58:20 +0800

来看这个代码

#include <iostream>
#include <string>
#include <map>

std::map<std::string, std::string> mapHttpRequest;

std::string GetString(std::string strKey)
{
    std::map<std::string, std::string>::iterator it = mapHttpRequest.find(strKey);
    if (it != mapHttpRequest.end())
    {
        return it->second;
    }    
    return "";
}

int SplitString()
{
    std::string strUrlParamValue = GetString("l");
    std::cout<<"before: "<<strUrlParamValue<<std::endl;
    char *pInOuter;
    char* p = strtok(const_cast<char*>(strUrlParamValue.c_str()), "|_");
    while (p)
    {
        std::cout<<"-> "<<p<<std::endl;
        p = strtok(NULL, "|_");
    }
    std::cout<<"after: "<<strUrlParamValue<<std::endl;
    return 0;
}

int main()
{
    mapHttpRequest["l"] = "4001|4002";
    SplitString();
    SplitString();
    return 0;
}

一般理解，连续调用两次 split string 函数，输出应该是完全一致的吧，嗯，来看结果

before: 4001|4002
-> 4001
-> 4002
after: 40014002
before: 40014002
-> 4001
after: 40014002

环境是 linux 2.6.16 64bit，gcc 的版本是 4.1.2

不过，在 vs 2005 下跑这个代码，得到的输出确实这样的

before: 4001|4002
-> 4001
-> 4002
after: 4001 4002
before: 4001|4002
-> 4001
-> 4002
after: 4001 4002

嗯，这个跟想象中的差不多吧

把细节打出来看看呗

#include <iostream>
#include <string>
#include <map>

std::map<std::string, std::string> mapHttpRequest;

std::string GetString(std::string strKey)
{
    std::map<std::string, std::string>::iterator it = mapHttpRequest.find(strKey);
    if (it != mapHttpRequest.end())
    {
        std::cout<<"map value addr: "<<(void*)it->second.c_str()<<std::endl;
        return it->second;
    }    
    return "";
}

int SplitString()
{
    std::string strUrlParamValue = GetString("l");
    std::cout<<"get string func return addr: "<<(void*)strUrlParamValue.c_str()<<std::endl;
    std::cout<<"before: "<<strUrlParamValue<<std::endl;
    char *pInOuter;
    char* p = strtok(const_cast<char*>(strUrlParamValue.c_str()), "|_");
    while (p)
    {
        std::cout<<(void*)p<<" -> "<<p<<std::endl;
        p = strtok(NULL, "|_");
    }
    std::cout<<"after: "<<strUrlParamValue<<std::endl;
    return 0;
}

int main()
{
    mapHttpRequest["l"] = "4001|4002";
    SplitString();
    SplitString();
    return 0;
}

先看 linux 下的结果

map value addr: 0x504098
get string func return addr: 0x504098
before: 4001|4002
0x504098 -> 4001
0x50409d -> 4002
after: 40014002
map value addr: 0x504098
get string func return addr: 0x504098
before: 40014002
0x504098 -> 4001
after: 40014002

再看 vs 2005 的执行结果

map value addr: 005D345C
get string func return addr: 0018FDF8
before: 4001|4002
0018FDF8 -> 4001
0018FDFD -> 4002
after: 4001 4002
map value addr: 005D345C
get string func return addr: 0018FDF8
before: 4001|4002
0018FDF8 -> 4001
0018FDFD -> 4002
after: 4001 4002

其中的原因，有可能是编译器的返回值优化，也有可能是 stl 的各自实现不同，现在过年了，没心情细究啊。。

gcc 编译时动态静态库的问题

Tue, 14 Jan 2014 10:08:41 +0800

一般来说，动态静态库的问题，可以参考这个文章，http://blog.csdn.net/ast_224/article/details/3988244

gcc生成静态库和动态库

一、库文件简介

简单地说，库（Library）就是一组已经写好了的函数和变量、经过编译代码，是为了能够提高开发效率和运行效率而设计的。库分为静态库（Static Library）和共享库（Shared library）两类。静态库文件的扩展名是.a，共享库文件的扩展名是.so（在CYGWIN环境下，分别叫做.o和.dll）。共享库现在常常被叫做动态库，是由于很多人借用了MS Windows的DLL（Dynamic Linked Library）这个词。（1）静态库静态是指每个用到该库的应用程序都拥有一份自己的库拷贝；应用程序运行的时候，即使将库删除也没有问题，因为应用程序自己已经有了自己的拷贝。（2）共享库一个共享库有可能被多个所有应用程序共享。因此，对每个应用程序来说，即使不再使用某个共享库，也不应将其删除。此外，应用程序需要正确的环境变量设置（LD_LIBRARY_PATH），从而找到共享库所在的位置，否则，应用程序运行时会报告找不到这个库。

二、关于使用库的问题

如果库是已经编译好的，那么如何在开发、运行应用程序时使用呢？头文件和库文件所在的路径，必须通过适当的方式通知给编译器、链接器和相关的应用程序。对于静态库来说，主要涉及开发工具，如gcc。例如，用gcc编译、链接时，需要通过适当的路径找到头文件和静态库文件；实现的方法有两种： gcc的命令行参数（-I, -L） shell的环境变量（C_INCLUDE_PATH, LIBRARY_PATH 对于共享库来说，程序在运行时，如果用到了动态库，也需要找到对应的动态库文件；实现的方法： shell的环境变量（LD_LIBRARY_PATH） 1） gcc命令行参数（-I, -L）默认情况下，gcc会自动搜索下面的路径：对头文件： /usr/local/include/ /usr/include/ 对库文件： /usr/local/lib/ /usr/lib/ 但是由于系统管理员对系统安装路径有不同的配置，或者对于如64位系统等情况，上述路径对于一台具体的计算机来说可能不同。如果开发者还有自己工程所需的头文件和库文件，就要用gcc的-I和-L来指定对应的路径。如果需要链接库，还要用-l选项。例如：如果工程涉及到GDBM（GNU DataBase Management）包，需要libgdbm库，而系统中安装GDBM的路径是：头文件：/opt/gdbm-1.8.3/include 库文件：/opt/gdbm-1.8.3/lib/ 那么，gcc的命令参数是： $gcc … -I/opt/gdbm-1.8.3/include -L/opt/gdbm-1.8.3/lib –lgdbm 注意：为保证兼容性，必须坚决杜绝在C/C++源文件的#include语句中或者其他相关语句中使用上述路径。 2） shell环境变量（Environmental Variable）除了用命令行参数，还可以用环境变量来指示gcc搜索适当的路径。而由于Shell的不同，环境变量的设置方法也不同。常用的Shell有Bash, Csh和Tcsh。（1）Bash 对于Bash来说，除了由系统管理员配置的内容以外，每个用户的用户目录（$HOME）下，有个.bash_profile文件。可在该文件内，增加下面的两个语句来设置GDBM头文件路径的环境变量： C_INCLUDE_PATH=/opt/gdbm-1.8.3/include export C_INCLUDE_PATH 类似地，在该文件内用下面的两个语句来设置库文件路径的环境变量： LIBRARY_PATH=/opt/gdbm-1.8.3/lib export LIBRARY_PATH 在.bash_profile中有了上述语句以后，就不用再使用-I和-L来搜索特定包的路径了。但是链接库的时候，还是要用-l选项。 $gcc … –lgdbm 在Bash下，要检查有什么样的环境变量，可用env命令。 $env （2）Csh和Tcsh 如果是Csh或Tcsh，对环境变量的设置方法就不同了。在用户的（$HOME）目录下，相关的一些文件如下： .cshrc 每次进入Csh时的启动(Startup)文件 .tcshrc 每次进入Tcsh时的启动(Startup)文件（在Tcsh下，如果没有这个文件，系统会用.cshrc文件代替） .login 每次登录Shell时的启动(Startup)文件在Csh和Tcsh下，分为Shell变量和环境变量；前者是用来设置Shell本身的，而后者则是供其他程序使用的。一般习惯是：Shell变量在.cshrc中定义，而环境变量则在.login文件中定义。定义Shell变量的方法是在.cshrc或.tcshrc中用set语句： set history = 20 定义环境变量的方法是在.login文件中用setenv语句。对于上面关于GDBM的例子： setenv C_INCLUDE_PATH /opt/gdbm-1.8.3/include setenv LIBRARY_PATH /opt/gdbm-1.8.3/lib 在Csh和Tcsh下，可以用setenv命令来查看设置了哪些环境变量（如果要看Shell变量，要用set命令）。注意： - 设置Shell变量时要用“=”号； - 设置环境变量时，变量名与实际值（这里是真实路径）之间没有“=”号; - 不需要export。 3）使用共享库使用共享库的应用程序，要通过环境变量LD_LIBRARY_PATH找到对应的共享库文件。与其他环境变量一样，对LD_LIBRARY_PATH也要根据shell的种类和库文件的实际路径进行设置。但是，必须注意的是，与一般的环境变量不同，LD_LIBRARY_PATH的值，是已经安装了的所有共享库的路径，因此，在Bash下，不能简单地用下面的办法： LD_LIBRARY_PATH=/opt/gdbm-1.8.3/lib 错误！ export LD_LIBRARY_PATH 而必须用： LD_LIBRARY_PATH=/opt/gdbm-1.8.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH 这样，就把其他共享库的路径也一起加入进来了。同样地，在Csh和Tcsh下， setenv LD_LIBRARY_PATH /opt/gdbm-1.8.3/lib:$LD_LIBRARY_PATH

三、关于库生成的问题我们通常把一些公用函数制作成函数库，供其它程序使用。函数库分为静态库和动态库两种。静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。

（1）静态库简单地说，静态库是一个目标文件的简单集合。因此，首先要解决目标文件。第一步：将各函数代码所在的源文件编译成目录文件。例如，对于myfunc.c, myproc.c gcc -c myfunc.c myproc.c 将得到myfunc.o和myproc.o。第二步：由ar（archive，归档的意思）把多个目标文件集合起来。 $ar -r libmyjob.a myfunc.o myproc.o 通常，静态库的命名方式应遵守libXXXXX.a格式。应用程序在使用静态库的时候，通常只需要把命名中的XXXXX部分传递给gcc即可。例如： $gcc –o mywork –lmyjob … 意为让gcc（实际上是gcc调用ld）去连接一个名字为libmyjob.a（或者libmyjob.so）的库。如果库的命名不遵循libXXXXX.a的格式就找不到相应文件。例子：创建静态库 hello.h为该函数库的头文件。hello.c是函数库的源程序，其中包含公用函数hello，该函数将在屏幕上输出" hello XXX!"。main.c为测试库文件的主程序，在主程序中调用了公用函数hello。程序1： //hello.h #ifndef HELLO_H #define HELLO_H void hello(const char *name); #endif 程序2： //hello.c #include void hello(const char *name) { printf(“hello %s! /n”,name); } 程序3： //main.c #include “hello.h” int main() { hello(“everyone”); return 0; }

实现步骤：第一步：必须将源程序hello.c通过gcc先编译成.o文件，生成hello.o（静态库/动态库，都是由.o文件创建的）；第二步：由.o文件创建静态库,生成libmyhello.a（静态库文件名的命名规范是以lib为前缀，紧接着跟静态库名，扩展名为.a）创建静态库用ar命令；第三步：在程序中使用静态库；（只需要在使用到这些公用函数的源程序中包含这些公用函数的原型声明，然后在用gcc命令生成目标文件时指明静态库名，gcc将会从静态库中将公用函数连接到目标文件中。注意，gcc会在静态库名前加上前缀lib，然后追加扩展名.a得到的静态库文件名来查找静态库文件）第四步：删除静态库文件，程序照常运行，静态库中的公用函数hello已经连接到目标文件main中了。运行： [root@localhost moduletest]# ls hello.c hello.h main.c [root@localhost moduletest]# gcc -c hello.c [root@localhost moduletest]# ls hello.c hello.h hello.o main.c [root@localhost moduletest]# ar crv libmyhello.a hello.o a - hello.o [root@localhost moduletest]# ls hello.c hello.h hello.o libmyhello.a main.c [root@localhost moduletest]# gcc main.c libmyhello.a -o main [root@localhost moduletest]# ./main hello everyone! [root@localhost moduletest]# rm -f libmyhello.a [root@localhost moduletest]# ls hello.c hello.h hello.o main main.c [root@localhost moduletest]# ./main hello everyone! [root@localhost moduletest]#

（2）共享库共享库的构造复杂一些，通常是一个ELF格式的文件。可以有三种方法生成： $ld -G $gcc -shared $libtool 用ld最复杂，用gcc -share就简单的多，但是-share并非在任何平台都可以使用。GNU提供了一个更好的工具libtool，专门用来在各种平台上生成各种库。用gcc的-shared参数： gcc –shared –o libmyjob.so myjob.o 这样，就通过myjob.o生成了共享库文件libmyjob.so。特别地，在CYGWIN环境下，仍需要输出符合Windows命名的共享库（动态库），即libXXXXX.dll。如： gcc –shared –o libmyjob.dll myjob.o

例子：创建动态库（延用上面的程序1，2，3）实现步骤：第五步：由.o文件创建动态库文件（命令：gcc -shared -fPCI -o libmyhello.so hello.o）；第六步：在程序中使用动态库；（在程序中使用动态库和使用静态库完全一样，也是在使用到这些公用函数的源程序中包含这些公用函数的原型声明，然后在用gcc命令生成目标文件时指明动态库名进行编译。程序在运行时，会在/usr/lib和/lib等目录中查找需要的动态库文件。若找到，则载入动态库，否则将提示错误信息而终止程序运行。要将文件libmyhello.so复制到目录/usr/lib中）运行： [root@localhost moduletest]# ls hello.c hello.h hello.o main.c [root@localhost moduletest]# gcc -shared -fPIC -o libmyhello.so hello.o [root@localhost moduletest]# ls hello.c hello.h hello.o libmyhello.so main.c [root@localhost moduletest]# gcc main.c libmyhello.so -o main [root@localhost moduletest]# ls hello.c hello.h hello.o libmyhello.so main main.c [root@localhost moduletest]# ./main ./main: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory [root@localhost moduletest]# mv libmyhello.so /usr/lib 可以： [root@localhost moduletest]# ls hello.c hello.h hello.o main main.c [root@localhost moduletest]# ./main hello everyone! [root@localhost moduletest]# 或者： [root@localhost moduletest]# rm -f main [root@localhost moduletest]# ls hello.c hello.h hello.o main.c [root@localhost moduletest]# gcc -Wall -g main.c -lmyhello -o main [root@localhost moduletest]# ls hello.c hello.h hello.o main main.c [root@localhost moduletest]# ./main hello everyone! [root@localhost moduletest]# 注意：当静态库和动态库同名时， gcc命令将优先使用动态库。

（3）库生成以后的配置如果要把自己开发的库文件安装到操作系统中，需要有管理员权限： (a) 把库文件复制到适当的目录：可以把自己开发的动态连接库放到/usr/local/lib（或者/usr/lib），或放到其他目录，但不论放在那里，都必须与LIBRARY_PATH的值、LD_LIBRARY_PATH的值相一致。 (b) 修改相关的系统配置文件：修改/etc/ld.so.conf，然后利用/sbin/ldconfig来完成。

Note: 编译参数解析最主要的是GCC命令行的一个选项: -shared 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件 l -fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。 l -L.：表示要连接的库在当前目录中 l -ltest：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称 l LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。 l 当然如果有root权限的话，可以修改/etc/ld.so.conf文件，然后调用 /sbin/ldconfig来达到同样的目的，不过如果没有root权限，那么只能采用输出LD_LIBRARY_PATH的方法了。调用动态库的时候有几个问题会经常碰到，有时，明明已经将库的头文件所在目录通过 “-I” include进来了，库所在文件通过 “-L”参数引导，并指定了“-l”的库名，但通过ldd命令察看时，就是死活找不到你指定链接的so文件，这时你要作的就是通过修改 LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了。

但是，奇葩的事情总是有的，我们现在面临的问题是，主程序是一个框架类型的可执行，这个框架跑起来之后，会用 dlopen 的方式，打开一个 so，业务逻辑在这个 so 里面，那么，自然的，这个 so 就是要用动态的方式来编译了，但是，这个 so 又依赖于 google pb，在部署的时候，环境并不保证有 pb，或者 pb 的版本并不保证匹配，那么，我们希望，把这个 pb 的库，静态的链接进来，也就是这个文章说道的，http://www.cnblogs.com/nobugtodebug/archive/2012/11/07/e6cd72c67b3dd843f40d7ce919f7336a.html

动态库(.so)链接静态库(.a)的情况总结一般来说在链接时想要使用静态库有三种方法： 1、link时加上 -static 选项；当加上 -static选项后，gcc会把所有用到的库都做静态连接。 2、link时直接指定想要静态连接的.a文件的绝对路径。优点是除非.a文件不存在，否则肯定有效；缺点也是很明显，拿到其他机器上编译时，.a文件也必须在相同的路径下存放。 3、在要静态连接的库前指定-Bstatic ，在要动态连接的库前指定-Bdynamic选项。连接器在看到-Bstatic时会优于去找静态库，如果找不到再去找动态库。 -Bdynamic也是同样的情况。（可是我实验的结果是这两个选项根本不起作用，我的环境是centos 6.2 gcc4.7.2, 仔细看了gcc 文档，这两个选项是针对VxWorks平台的，所以不起作用。）当我们要编译一个so提供给外部使用，这个so本身依赖一些第三方库。但是我们却希望so的使用者不用关心该so对其他库的依赖。很自然的是会想到在编译so的时候把依赖到的第三方库静态链接进来。我在这样做的时候碰到了问题：指定-static选项时，link失败，错误提示说要用到的object文件应该用-fPIC选项重新编译才行（也就是说，只有用-fPIC选项编译的object文件能被link到.so里）；当直接给出.a的绝对路径的时候link成功，但是.so里却并没有直正包含所用到的符合连接。针对碰到的问题，我做了一些实验。实验如下： static.c

#include const char* sz_static = “i’m a static str.”; void print_niuzai_said() { printf(“in static lib, niu zai said, i’m happy!\n”); } dynamic.c #include #include “static.h” void print_papa_said() { print_niuzai_said(); printf(“in dynamic lib, papa said, niu zai is wonderful!\n”); } main.c #include #include “dynamic.h” int main(int argc, char** argv) { print_papa_said(); return 0; } 分别用两组命令编译出了两个.a 文件 1、gcc -o static.o -c static.c ar -r libstatic.a static.o 2、gcc -o static_shared.o -shared -fPIC -c static.c ar -r libstatic_shared.a static_shared.o 然后用此命令 “gcc -o dynamic.o -c dynamic.c” 编译出dynamic.o文件接下来就是本文的主题了，链接生成libdynamic.so.此时有这么几种情况： 1、使用 “gcc -o libdynamic.so -shared -fPIC -L. -lstatic dynamic.o “，连接成功，但.so里实际上没有static.o里的内容。 2、使用"gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic”,连接失败 3、使用 “gcc -o libdynamic.so -shared -fPIC -L. -lstatic_shared dynamic.o”，连接成功，但.so里实际上没有static.o里还是没有的内容。 4、使用 “gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic_shared”,连接成功，.a的内容被连接到了.so里面。另外，链接静态生成可执行程序时，静态库是不是用 “-shared -fPIC” 选项编译产生的没有影响。都能正常生成可执行程序。综合以上情况，总结如下： 1、动态连接库中用到的object文件必须是用 “-shared -fPIC"选项编译产生的，否则连接时要么报错，要么被忽略。 2、静态库中的object文件最好也用”-shared -fPIC"选项编译，这样静态库就可以同时被连接到.so 或者可执行性文件中。 3、动态库只能连接用”-shared -fPIC"选项编译出来的静态库（和第1点是同一件事） 4、连接选项的顺序对连接器的行为有重要影响！静态库使用-shared -fPIC 连接命令连接执行结果动态库结果最终结果否 gcc -o libdynamic.so -shared -fPIC -L. -lstatic dynamic.o 成功静态库内容没有被连接失败否 gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic 失败失败是 gcc -o libdynamic.so -shared -fPIC -L. -lstatic_shared dynamic.o 成功静态库内容没有被连接失败是 gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic_shared 成功静态库内容被连接成功

直接链接 lib.a 的文件，会报错，要求 fPIC，看到这个文章，http://hi.baidu.com/88908775/item/4c147df59c218d1fa62988c6，里面提供了两种方式，一个改 configure，一个是改 Makefile，改 Makefile 在我这个尝试了不行，改 configure 可以

环境： gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) 64位

google protobuf 2.4.1

问题：在使用libprotobuf.a文件时，编译错误 libprotobuf.a(common.o): relocation R_X86_64_32S against `std::basic_string, std::allocator >::_Rep::_S_empty_rep_storage’ can not be used when making a shared object; recompile with -fPIC

原因： -fPIC 是个神马东东呢？选项 -fPIC PIC是Position-Independent-Code的缩写。在计算机系统中，PIC和PIE(Position-IndependentExecutable)是可以在主存中不同位置执行的目标代码。PIC经常被用在共享库中，这样就能将相同的库代码为每个程序映射到一个位置，不用担心覆盖掉其他程序或共享库。

因为so动态库编译的时候加上了 -fPIC，但是连接的 libprotobuf.a文件并不是 -fPIC生成的，所以就报错了。那就是说连接的 libprotobuf.aa 文件，也需要加上 -fPIC 选项进行编译了。

解决方法：

以文本形式打开google buff代码目录下的configure文件，在把第2575至2578行修改为如下： if test “x${ac_cv_env_CFLAGS_set}” = “x”; then : CFLAGS="-fPIC" fi if test “x${ac_cv_env_CXXFLAGS_set}” = “x”; then : CXXFLAGS="-fPIC" 再次执行configure： configrue –disable-shared make make install 编译完成后,使用libprotobuf.a文件，以上问题解决。

或者修改 google protobuf的 Makefile文件，加上 -fPIC 选项，重新编译生成 libprotobuf.a文件

参考资料：

详细说明-fPIC的工作原理： http://blog.csdn.net/chrisniu1984/article/details/6620665

-DPIC 是一个宏定义预处理标识 http://gcc.gnu.org/ml/gcc-help/2006-10/msg00147.html

http://www.lingcc.com/2009/11/20/10065/ http://canlynet.blog.163.com/blog/static/25501365201191145113156/ 编译动态库时遇到如下错误： … … relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object; recompile with -fPIC … could not read symbols: Bad value

解决办法编译器已经提示了：recompile with -fPIC 但是我们应该重新编译谁带上这个参数呢？经过我几番折腾，发现如下情况： 1、编译.o文件的时候，没有加参数-fPIC，这问题个在gcc version 3.4.6版本没有发生，可能那个编译器默认都给加上吧。 2、当前程序中有用到某个静态库，那个静态库编译.o文件的时候没有加上-fPIC（静态库其实就是.o文件打包）。补充一点：我发现手写Makefile时即使不加-fPIC也没有这个问题，这一点很郁闷，这个只在用automake工具编译出.a文件时才出现过。知道原因了，解决办法自然有了，保证你编译.o文件的时候，都加上-fPIC，这样你才能编译出动态库来。

http://bbs.chinaunix.net/thread-1035042-1-1.html 从GCC来看，shared应该是包含fPIC选项的，但似乎不是所以系统都支持，所以最好显式加上fPIC选项。参见如下

`-shared’ Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options that were used to generate code (`-fpic’, `-fPIC’, or model suboptions) when you specify this option.(1)

gcc 编译时输出有问号

Tue, 31 Dec 2013 11:20:18 +0800

今天切到一台新的机器上去开发，编译的时候发现 gcc 的输出带着问号，就像这个样子

src/BusiObj.cpp: In member function ?.nt CBusiObj::DecodeUdp(int&, int&, const char*, int)?.
src/BusiObj.cpp:287: warning: format ?.d?.expects type ?.nt?. but argument 6 has type ?.ong unsigned int?
src/BusiObj.cpp:300: warning: format ?.u?.expects type ?.nsigned int?. but argument 7 has type ?._time_t?

看起来十分难受，查了一下是终端字符编码的问题，用 echo $LANG 看一下系统的编码，把终端的编码跟随的调整一下就可以了，修改完成后就是正常的了

src/BusiObj.cpp: In member function ‘int CBusiObj::DecodeUdp(int&, int&, const char*, int)’:
src/BusiObj.cpp:287: warning: format ‘%d’ expects type ‘int’, but argument 6 has type ‘long unsigned int’
src/BusiObj.cpp:300: warning: format ‘%u’ expects type ‘unsigned int’, but argument 7 has type ‘__time_t’

gcc 编译选项顺序导致的找不到定义

Thu, 12 Sep 2013 09:47:05 +0800

在使用 gcc 或者 g++ 进行编译，并链接外部的库的时候，发现了一个问题，明明使用了 -L 参数对库文件指明了链接，但是依然出错，报找不到定义，后来问过小组的人，才知道 gcc 的编译选项也有讲究的，看到这里，http://blog.csdn.net/lonfee88/article/details/6029540：

对于C/C++编译而言，读取编译选项是按照从左到右的顺序执行的(注1) 。那么当编译器遇到源文件的时候，就开始对源文件中用到的函数进行解析，找到相对应的函数的函数体或者说是实现（Definition of Function）。这个过程是按照先遇到不能解析的函数（unresolved function），然后在源文件选项后面的一些选项中寻找可能的函数体的信息，是这样的一个顺序进行的。那么我们可以发现对于Makefile A，由于包含函数体或者函数定义信息的编译选项出现在源文件之前，那么当编译器在源文件中遇到不能解析的函数时，在源文件之后的选项中寻找相关的信息，那么就出现了编译错误，也就是无法找到相关的函数定义。

所以解决的方式是，把链接的 -L 选项放到后面去

GCC "-fomit-frame-pointer"编译选项的含义

Thu, 22 Aug 2013 15:52:18 +0800

在 makefile 中看到这个编译选项，不太理解于是查了一下，相关的东西还不多，抄一下放在这里

首先这个文章，http://blog.csdn.net/byzs/article/details/2220461，讲的不错，挺清晰的：

优化你的软件时，发觉"-fomit-frame-pointer"这个选项还是蛮有用的。

GCC手册上面这么说： Don’t keep the frame pointer in a register for functions that don’t need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn’t exist. The machine-description macro “FRAME_POINTER_REQUIRED” controls whether a target machine supports this flag.

这里，引入了一个"frame pointer"的概念，什么是"stack frame pointer(SFP)“呢？

我们知道，backtrace是利用堆栈中的信息把函数调用关系层层遍历出来的，其中这里的堆栈信息就是SFP。一般情况下，每一个函数都包含一个堆栈边界指针，也就是说会存在一个栈底和栈顶指针。在X86下，假设堆栈由上往下发展，栈底大地址而栈顶小地址，那么，通常情况下，寄存器ESP为栈顶指针，而EBP就为栈底指针。而EBP和ESP之间的空间就是这个函数的stack frame。 GCC在默认情况下会在每个函数的开始加入一些堆栈设置代码，而在函数退出的时候恢复原来的样子，SFP就是在这个时候设置的。还是看一下这个时候的汇编代码吧 ;-)

环境：X86+Redhat 9.0，gcc 3.2.2

源文件如下：

$ cat test.c void a(unsigned long a, unsigned int b) { unsigned long i; unsigned int j;

        i = a; j = b;

        i++;

        j += 2;

}

默认编译选项： $ gcc -c test.c -o with_SFP.o

反汇编后是这个样子： $ objdump -D with_SFP.o

with_SFP.o:     file format elf32-i386

Disassembly of section .text:

00000000 : 0:   55                      push   %ebp 1:   89 e5                   mov    %esp,%ebp 3:   83 ec 08                sub    $0x8,%esp 6:   8b 45 08                mov    0x8(%ebp),%eax 9:   89 45 fc                mov    %eax,0xfffffffc(%ebp) c:   8b 45 0c                mov    0xc(%ebp),%eax f:   89 45 f8                mov    %eax,0xfffffff8(%ebp) 12:   8d 45 fc                lea    0xfffffffc(%ebp),%eax 15:   ff 00                   incl   (%eax) 17:   8d 45 f8                lea    0xfffffff8(%ebp),%eax 1a:   83 00 02                addl   $0x2,(%eax) 1d:   c9                      leave 1e:   c3                      ret Disassembly of section .data:

可以看到函数ENTER时首先把上一层函数的EBP入栈，设置本函数的EBP，然后会根据临时变量的数量和对齐要求去设置ESP，也就产生了函数的stack frame。我们再看看函数的返回：“leave"指令相当于"mov %ebp,%esp;pop %ebp”,也就是ENTER是两条指令的恢复过程，所以，后面的"ret"指令和"call"指令对应。这里backtrace就可以根据现有函数EBP指针得知上一个函数的EBP—-栈底再往上保存着上一个函数的EBP和EIP，然后就可以得知函数调用的路径。

SFP是可以在编译时候优化掉的，用”-fomit-frame-pointer"选项

编译： $ gcc -fomit-frame-pointer -c test.c -o no_SFP.o

$ objdump -D no_SFP.o

no_SFP.o:     file format elf32-i386

Disassembly of section .text:

00000000 : 0:   83 ec 08                sub    $0x8,%esp 3:   8b 44 24 0c             mov    0xc(%esp,1),%eax 7:   89 44 24 04             mov    %eax,0x4(%esp,1) b:   8b 44 24 10             mov    0x10(%esp,1),%eax f:   89 04 24                mov    %eax,(%esp,1) 12:   8d 44 24 04             lea    0x4(%esp,1),%eax 16:   ff 00                   incl   (%eax) 18:   89 e0                   mov    %esp,%eax 1a:   83 00 02                addl   $0x2,(%eax) 1d:   83 c4 08                add    $0x8,%esp 20:   c3                      ret Disassembly of section .data: 这里把EBP省掉了，ESP兼职了EBP的部分工作（索引临时变量）。显而易见，代码难懂了;-P，代码执行长度缩短了，应该能引起效率的提升。可恶的是，不能用backtrace调试了。

看一下arm下面的情况：含有SFP的版本： $ arm-linux-objdump -D SFP_arm.o

SFP_arm.o :     file format elf32-littlearm

Disassembly of section .text:

00000000 : 0:   e1a0c00d        mov     ip, sp 4:   e92dd800        stmdb   sp!, {fp, ip, lr, pc} 8:   e24cb004        sub     fp, ip, #4      ; 0x4 c:   e24dd010        sub     sp, sp, #16     ; 0x10 10:   e50b0010        str     r0, [fp, -#16] 14:   e50b1014        str     r1, [fp, -#20] 18:   e51b3010        ldr     r3, [fp, -#16] 1c:   e50b3018        str     r3, [fp, -#24] 20:   e51b3014        ldr     r3, [fp, -#20] 24:   e50b301c        str     r3, [fp, -#28] 28:   e51b3018        ldr     r3, [fp, -#24] 2c:   e2833001        add     r3, r3, #1      ; 0x1 30:   e50b3018        str     r3, [fp, -#24] 34:   e51b301c        ldr     r3, [fp, -#28] 38:   e2833002        add     r3, r3, #2      ; 0x2 3c:   e50b301c        str     r3, [fp, -#28] 40:   e91ba800        ldmdb   fp, {fp, sp, pc} Disassembly of section .data:

优化后的版本： $ arm-linux-objdump -D no_SFP_arm.o

no_SFP_arm.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 : 0:   e24dd010        sub     sp, sp, #16     ; 0x10 4:   e58d000c        str     r0, [sp, #12] 8:   e58d1008        str     r1, [sp, #8] c:   e59d300c        ldr     r3, [sp, #12] 10:   e58d3004        str     r3, [sp, #4] 14:   e59d3008        ldr     r3, [sp, #8] 18:   e58d3000        str     r3, [sp] 1c:   e59d3004        ldr     r3, [sp, #4] 20:   e2833001        add     r3, r3, #1      ; 0x1 24:   e58d3004        str     r3, [sp, #4] 28:   e59d3000        ldr     r3, [sp] 2c:   e2833002        add     r3, r3, #2      ; 0x2 30:   e58d3000        str     r3, [sp] 34:   e28dd010        add     sp, sp, #16     ; 0x10 38:   e1a0f00e        mov     pc, lr Disassembly of section .data:

这里，“fp"充当了"EBP"的角色，ESP在X86里面被leave隐含的恢复好了，所以没有显示设置的必要。看起来arm平台上”-fomit-frame-pointer"选项的优化作用更加明显。

然后后面又看到这里，http://zhouzhen1.blogbus.com/logs/10843069.html，也讲到函数调用的压栈过程的 ebp，esp 指针的问题，但是感觉没太看懂：

今天下班前看了一下工作中涉及到的C++程序在VS.net环境中的编译选项。发现其中很多东西对我来说很陌生，公司的手册只是告诉我哪些要怎么设置，但并不提这个参数有什么意义，或者这样设的目的是什么。

刚才上网查了有关omit frame pointer的资料，

http://www.codeproject.com/tips/stackdumper.asp

我们说所谓函数调用反映在汇编层面表现为对栈的操作，而frame pointer指的是一个叫做ebp的寄存器，其中存放该函数的基址。发生函数调用时，调用者首先将函数变量以及返回地址入栈，而后代码指针转入被调用函数，这里首先将调用者的基址（已在调用者开始时存在ebp中）入栈，同时将自己的基址记入ebp，然后修改栈顶指针esp以容纳被调用函数自身的局部变量，函数退出时，将栈顶指针恢复至自己的基址（从ebp中取得），然后将调用者的基址弹出至ebp并返回。

所以说ebp用于记录函数的基址，用于在函数返回时的清栈工作。而在上面的链接中，作者提出利用这个处理过程的汇编代码来寻找栈操作汇编代码。

那么为什么VS.net可以忽略frame pointer？如果忽略的话，函数返回时岂不是不知道自己的基址了，怎么完成退栈呢？网上没人提这个，我想会不会是因为在编译过程中其实已经可以知道这个信息，所以直接把一个立即数赋给esp就可以了？

后面又看到这里，http://stackoverflow.com/questions/1942801/when-should-i-omit-the-frame-pointer，也讲到 ebp 可以减少栈操作：

-fomit-frame-pointer allows one extra register to be available for general-purpose use. I would assume this is really only a big deal on 32-bit x86, which is a bit starved for registers.*

One would expect to see EBP no longer saved and adjusted on every function call, and probably some additional use of EBP in normal code, and fewer stack operations on occasions where EBP gets used as a general-purpose register.

Your code is far too simple to see any benefit from this sort of optimization– you’re not using enough registers. Also, you haven’t turned on the optimizer, which might be necessary to see some of these effects.

* ISA registers, not micro-architecture registers.

而这里，http://stackoverflow.com/questions/14666665/trying-to-understand-gcc-option-fomit-frame-pointer，也讲到了，在简单的上下文环境中，这个选项其实是意义不大的：

Most smaller functions don’t need a frame-pointer - larger functions MAY need one.

It’s really about how well the compiler manages to track how the stack is used, and where things are on the stack (local variables, arguments passed to the current function and arguments being prepared for a function about to be called). I don’t think it’s easy to characterize the functions that need or don’t need a frame-pointer [technically, NO function HAS to have a frame-pointer - it’s more a case of “if the compiler deems it necessary to reduce the complexity of other code”].

I don’t think you should “attempt to make functions not have frame-pointer” as part of your strategy for coding - like I said, simple functions don’t need them, so use -fomit-frame-pointer, and you’ll get one more register available for the register allocator, and save 1-3 instructions on entry/exit to functions. If your function needs a frame-pointer, it’s because the compiler decides that’s a better option than using frame pointer. It’s not a goal to have functions without frame pointer, it’s a goal to have code that works both correctly and fast.

Note that “not having framepointer” should give better performance, but it’s not some magic bullet that gives enormous improvements - particularly not on x86-64, which already has 16 registers to start with. On 32-bit x86, since it only has 8 registers, one of which is stackpointer, and taking up another as the frame-pointer means 25% of register-space is taken. To change that to 12.5% is quite an improvement. Of course, compiling for 64-bit will help quite a lot too.

最后，gnu gcc 的文档这里，http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html，讲到了这个选项的默认配置：

-fomit-frame-pointerDon’t keep the frame pointer in a register for functions that don’t need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn’t exist. The machine-description macro FRAME_POINTER_REQUIRED controls whether a target machine supports this flag. See Register Usage.

Enabled at levels -O, -O2, -O3, -Os.

printf 一定需要 stdio.h 吗

Sun, 30 Sep 2012 09:01:32 +0800

刚刚看到一个范例代码，调用了 printf 函数，但是却没有包含 stdio.h 的头文件，这种写法第一反应就应该是不对的啊，本着动手实验的原则，试了一下

zrj@vm:~/c/test$ cat test.c
int main() {
    printf("hello worldn");
    return 0;
}
zrj@vm:~/c/test$ gcc -o test test.c
test.c: 在函数‘main’中:
test.c:2:5: 警告： 隐式声明与内建函数‘printf’不兼容 [默认启用]
zrj@vm:~/c/test$ ./test
hello world

发现确实是可以的，gcc 在编译的时候给了一个警告，但是能够正常的生成可执行文件，而且也能正常的运行出结果，找了一下，在这里，http://wiki.ubuntu.org.cn/Gcchowto，找到解释

链接外部库库是预编译的目标文件(object files)的集合，它们可被链接进程序。静态库以后缀为‘.a’的特殊的存档文件(archive file)存储。

标准系统库可在目录 /usr/lib 与 /lib 中找到。比如，在类 Unix 系统中 C 语言的数学库一般存储为文件 /usr/lib/libm.a。该库中函数的原型声明在头文件 /usr/include/math.h 中。C 标准库本身存储为 /usr/lib/libc.a，它包含 ANSI/ISO C 标准指定的函数，比如‘printf’。对每一个 C 程序来说，libc.a 都默认被链接。

============================================

2012-10-05 14:27:11 update 在这里，http://zhidao.baidu.com/question/341065125.html?seed=0，有更好的解释

由于编译器在处理函数调用代码时没有找到函数原型，只好根据函数调用代码做隐式声明. 为什么编译器在处理函数调用代码时需要有函数原型？因为必须知道参数的类型和个数以及返回值的类型才知道生成什么样的指令。为什么隐式声明靠不住呢？因为隐式声明是从函数调用代码推导而来的，而事实上函数定义的形参类型可能跟函数调用代码传的实参类型并不一致，如果函数定义带有可变参数（例如printf），那么从函数调用代码也看不出来这个函数带有可变参数，另外，从函数调用代码也看不出来返回值应该是什么类型，所以隐式声明只能规定返回值都是int型的。既然隐式声明靠不住，那编译器为什么不自己去找函数定义，而非要让我们在调用之前写函数原型呢？因为编译器往往不知道去哪里找函数定义.