由学习SystemServer引发的extern "C "探究

在学习SystemServer时，根据函数调用发现，从SystemServer.java::main--->init1--->com_android_SystemServer.cpp::android_server_SystemServer_init1--->system_init时，system_init函数在cpp文件的最上面声明了

extern "C" int system_init();

但是没有包含头文件啊之类的，那系统是如何找到system_init函数的呢？

 

上网查了一些资料，发现《 条件编译和extern "C"的用法总结》文章中这样总结道：[这篇文章确实写得很不错，强烈推荐!!!]

在C++.cpp文件中也可以不用包含函数声明的文件，即“extern "C"{#include"cHeader.h"}”，而直接改用extern "C" void print(int i)的形式。那C++.cpp是如何找到C中的print函数，并调用的呢？

那是因为我们首先通过gcc -c cHeader.c 这个命令，产生了一个cHeader.c的目标文件。然后我们通过执行g++ -o C++ C++.cpp cHeader.o这个命令，该命令中指明了要链接的目标文件：cHeader.o，所以C++.cpp中只需要说明哪些函数（比如该题中的void print(int i)）需要以C的形式调用，然后去其目标文件(这里为cHeader.o)中找该函数即可。

 

那么回到之前的函数调用流程，找到system_init函数的定义，在framwork/base/cmds/system_server/library/system_init.cpp文件中。同时在/library目录下，还有一个Android.mk文件。在该文件中通过

LOCAL_MODULE:= libsystem_server
include $(BUILD_SHARED_LIBRARY)

知道最后生成的是动态库，名为libsystem_server.so

 

那么，寻找android_server_SystemServer_init1函数所在的路径中的Android.mk文件，看看是否有包含libsystem_server.so动态库，如果包含了，那就说明编译时，系统会自动在该库中查找system_init函数的定义，调用该函数。

路径为framework/base/services/jni/Android.mk

LOCAL_SHARED_LIBRARIES := \
   libandroid_runtime \
   libcutils \
   libhardware \
   libhardware_legacy \
   libnativehelper \
   libsystem_server \
   libutils \
   libui \
   libsurfaceflinger_client

O(∩_∩)O~，看到了吧~~~大功告成，happy one day~~

摘自《 条件编译和extern "C"的用法总结》

2.3、小结extern "C"

        通过上面两节的分析，我们知道extern "C"的真实目的是实现类C和C++的混合编程。在C++源文件中的语句前面加上extern "C"，表明它按照类C的编译和连接规约来编译和连接，而不是C++的编译的连接规约。这样在C++的代码中就可以调用类C的函数or变量等。（注：我在这里所说的类C，代表的是跟C语言的编译和连接方式一致的所有语言。

        下面再给出一个具体的实例进行分析：

(1)未加extern “C”声明时的编译方式
        作为一种面向对象的语言，C++支持函数重载，而过程式语言C则不支持。函数被C++编译后在符号库中的名字与C语言的不同。假设某个函数的原型为：void foo( int x, int y );
　　该函数被C编译器编译后在符号库中的名字为_foo，而C++编译器则会产生像_foo_int_int之类的名字（不同的编译器可能生成的名字不同，但是都采用了相同的机制，生成的新名字称为“mangled name”）。
　　_foo_int_int这样的名字包含了函数名、函数参数数量及类型信息，C++就是靠这种机制来实现函数重载的。例如，在C++中，函数void foo( int x, int y )与void foo( int x, float y )编译生成的符号是不相同的，后者为_foo_int_float。

        同样地，C++中的变量除支持局部变量外，还支持类成员变量和全局变量。用户所编写程序的类成员变量可能与全局变量同名，我们以"."来区分。而本质上，编译器在进行编译时，与函数的处理相似，也为类中的变量取了一个独一无二的名字，这个名字与用户程序中同名的全局变量名字不同。
(2)未加extern "C"声明时的连接方式
        假设在C++中，模块A的头文件如下：

// 模块A头文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
int foo( int x, int y );
#endif

       在模块B中引用该函数：

// 模块B实现文件　moduleB.cpp
#include "moduleA.h"
foo(2,3);

 实际上，在连接阶段，连接器会从模块A生成的目标文件moduleA.obj中寻找_foo_int_int这样的符号！

(3)加extern "C"声明后的编译和连接方式

    加extern "C"声明后，模块A的头文件变为： 

// 模块A头文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
extern "C" int foo( int x, int y );
#endif

在模块B的实现文件中仍然调用foo( 2,3 )，其结果是：
  (1)模块A编译生成foo的目标代码时，没有对其名字进行特殊处理，采用了C语言的方式；
  (2)连接器在为模块B的目标代码寻找foo(2,3)调用时，寻找的是未经修改的符号名_foo。
如果在模块A中函数声明了foo为extern "C"类型，而模块B中包含的是extern int foo( int x, int y ) ，则模块B找不到模块A中的函数；反之亦然。
所以，可以用一句话概括extern “C”这个声明的真实目的（任何语言中的任何语法特性的诞生都不是随意而为的，来源于真实世界的需求驱动。）：实现C++与C及其它语言的混合编程。