Android上层如何调用一个底层函数

1. 背景

本文讲的是调用流程，如何找到相应代码位置，更多的是一种分析代码的方式。

此处将从ZygoteInit调用Zygote.forkSystemServer函数开始跟踪代码直到fork根据父进程和子进程返回pid为止，这会是从上到下的一条简单而通用的例子。

本文的代码是基于Android O的MR0进行分析(kernel仍然是kernel-3.18)，MR1正式释放要等到11月吧(kernel google建议是kernel-4.4)

2. Android fork进程的流程

Android要创建一个进程，肯定要调用底层的fork(android 2.3)或者clone(android O)函数，这个意味着上层需要调用到kernel的函数。

这个行为将从JAVA通过JNI调用到C++的代码，再通过C++调用bionic(经过裁剪和优化，为了调用kernel相关内容，可以任何是kernel的GNU接口)，然后在syscall到kernel底层函数(以前fork还会经过汇编，目前的这个函数调用并不会)。

我们分为2条线走，一条是Android到bionic，一条是bionic到kernel

2.1 Android到bionic

Android到bionic，我认为是都属于Android的一部分。

2.1.1 ZygoteInit.java启动系统服务

private static boolean startSystemServer(String abiList, String socketName, ZygoteServer zygoteServer)

...

/* Request to fork the system server process */

pid = Zygote.forkSystemServer(

本文不关注具体传递参数，故上述只关注从一个文件调用到另一个文件，以文件结构去梳理

frameworks/base/core/java/com/android/internal/os/ZygoteInit.java 调用到 =>

frameworks/base/core/java/com/android/internal/os/Zygote.java

此处有个pid，就是fork返回的值，众所周知，这个父进程返回的是子进程的pid，子进程返回的是0，后面我们也就是跟踪这一条线到返回pid为止。

2.1.2 Zygote.java创建系统服务进程

public static int forkSystemServer(int uid, int gid, int[] gids, int debugFlags,

...

int pid = nativeForkSystemServer(

...

此处会从java调用到C++的函数，使用的就是类似与JNI的方式，这类行为不在本文阐述范围内

frameworks/base/core/java/com/android/internal/os/Zygote.java 调用到 =>

frameworks/base/core/jni/com_android_internal_os_Zygote.cpp

2.1.3 com_android_internal_os_Zygote.cpp本地函数

//此类函数会注册到虚拟机中

static const JNINativeMethod gMethods[] = {

//第一个是上层java调用函数的名字

//第二个是函数的参数和返回值，这里不会细讲

//第三个就是转换给本地的函数

{ "nativeForkSystemServer", "(II[II[[IJJ)I",

(void *) com_android_internal_os_Zygote_nativeForkSystemServer },

//...

//转换后的本地函数，一般都是以报名字进行拼接

static jint com_android_internal_os_Zygote_nativeForkSystemServer(

....

//内部调用另一个ForkAndSpecializeCommon函数

return ForkAndSpecializeCommon(env, uid, gid, gids, debug_flags,

....

static pid_t ForkAndSpecializeCommon(JNIEnv* env, uid_t uid,

...

//上述其实对于本条流程可以通通不关注，到这里才是重点，调用fork函数，

//注意，此处还不是linux的fork，只是准备调用bionic的fork

pid_t pid = fork();

里面有很多内容，我们直接跳过，还是刚才说的本文主要阐述的是跟踪代码的方式，后续大家可以直接去尝试跟进，根据大的文件目录结构往往都可以找到自己想要的答案(这个大文件架构从android2.3开始就没有特别大的变动)

frameworks/base/core/jni/com_android_internal_os_Zygote.cpp 调用到 =>

bionic/libc/bionic/fork.cpp

2.1.4 fork.cpp用于fork进程

int fork() {

....

int result = clone(nullptr,

....

此处已经是bionic的内容，这里接下去会调用bionic中的clone函数(android 2.3的时候是直接进入fork的汇编)

好了到这里第一部分暂时讲完了，Android如果需要和kernel通信，一般都是需要经过bionic的，如果后续大家看到类似linux的函数可以先在bionic找找，当然你也可以直接在kernel代码中找(如果不关注这些流程，这个会更快，一般这类流程看一遍知道了就不会再看了)

2.2 bionic到kernel的系统调用

接下来需要讲解的是从bionic到kernel的系统调用，还是接着上面的clone函数讲解

* bionic/libc/bionic/fork.cpp 调用到 =>

* bionic/libc/bionic/clone.cpp

2.2.1 clone.cpp克隆进程

int clone(int (*fn)(void*), void* child_stack, int flags, void* arg, ...) {

...

//这里64位和32位很多都是有区分的，此处最后2个参数是经过翻转的

#if defined(__x86_64__) // sys_clone's last two arguments are flipped on x86-64.

clone_result = syscall(__NR_clone, flags, child_stack, parent_tid, child_tid, new_tls);

#else

clone_result = syscall(__NR_clone, flags, child_stack, parent_tid, new_tls, child_tid);

#endif

...

此处syscall的函数是__NR_clone，如果是64位，其定义在kernel-3.18/arch/arm64/include/asm/unistd32.h中

bionic/libc/bionic/clone.cpp 调用到 =>

kernel-3.18/arch/arm64/include/asm/unistd32.h

2.2.2 unistd32.h系统调用定义

//kernel-3.18/arch/arm64/include/asm/unistd32.h

__SYSCALL(__NR_clone, sys_clone)

很简单的一句话__SYSCALL，其实际代表的意思是__NR_clone这个函数就是sys_clone，具体我们还得看看__SYSCALL的定义

具体定时在kernel-3.18/arch/arm64/kernel/sys.c中 =>

//kernel-3.18/arch/arm64/kernel/sys.c

#define __SYSCALL(nr, sym) [nr] = sym,

好了接下去我们就需要看sys_clone这个函数具体是哪里调用的，我们搜索整份源代码发现，并未有以sys_clone开通的函数，那它跑去哪里了呢？

2.2.3 syscalls.h系统调用的头文件

//kernel-3.18/include/linux/syscalls.h

#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)

由于已经知道后续具体调用的就是SYSCALL_DEFINE5(clone…，这个提前跟大家说一下，第一次查看代码可以通过反推，后面就没有必要了。

注意##代表链接符，”_##name”对于clone来说，就是”_clone”

所以我们先来看看里面的一堆SYSCALL_DEFINE+1,2,3…这样的函数，类似于SYSCALL_DEFINE5(name, …)其宏定义是SYSCALL_DEFINEx(5, _##name, VA_ARGS)，也就是下面类似的=>

#define SYSCALL_DEFINEx(x, sname, ...) \

//SYSCALL_METADATA这个东西暂时无需关注，定义一些syscall的数据结构，此处先关注函数定义

SYSCALL_METADATA(sname, x, __VA_ARGS__) \

__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

上面转换SYSCALL_DEFINEx为__SYSCALL_DEFINEx，这个也是一个宏定义=>

#define __SYSCALL_DEFINEx(x, name, ...) \

asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \

__attribute__((alias(__stringify(SyS##name)))); \

...

好吧上面又多了2个宏__MAP和__SC_DECL，不过终于我们看到函数名字了sys##name。针对sys_clone函数来说，SYSCALL_DEFINE5(clone的函数名字其实和sys_clone是一样的。

顺便看一下__MAP和__SC_DECL的宏定义

//__SC_DECL这个宏只是将里面的2个参数变成一前一后的形式而已，这需要结合__MAP一起看

#define __SC_DECL(t, a) t a

//__MAP(x的意思就是调用__MAPx而已，__MAPx其实就是将每2个参数组合成一个，英文解释也比较清楚

//__MAP(n, m, t1, a1, t2, a2, ..., tn, an) will expand to

// m(t1, a1), m(t2, a2), ..., m(tn, an)

#define __MAP0(m,...)

#define __MAP1(m,t,a) m(t,a)

#define __MAP2(m,t,a,...) m(t,a), __MAP1(m,__VA_ARGS__)

#define __MAP3(m,t,a,...) m(t,a), __MAP2(m,__VA_ARGS__)

#define __MAP4(m,t,a,...) m(t,a), __MAP3(m,__VA_ARGS__)

#define __MAP5(m,t,a,...) m(t,a), __MAP4(m,__VA_ARGS__)

#define __MAP6(m,t,a,...) m(t,a), __MAP5(m,__VA_ARGS__)

#define __MAP(n,...) __MAP##n(__VA_ARGS__)

类似与SYSCALL_DEFINE5(clone通过上述转换=>

//宏定义原型

SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,

int __user *, parent_tidptr,

int __user *, child_tidptr,

int, tls_val)

=>

SYSCALL_DEFINEx(5, _clone, __VA_ARGS__)

=>

__SYSCALL_DEFINEx(5, _clone, __VA_ARGS__)

=>

sys_clone(__MAP(5,__SC_DECL,__VA_ARGS__))

=>两两凑对，共5个参数

sys_clone(unsigned long clone_flags, unsigned long newsp,

int __user * parent_tidptr,

int __user * child_tidptr,

int tls_val

这里和 2.2.1 的syscall(__NR_clone, flags, child_stack, parent_tid, child_tid, new_tls)函数调用传递的参数是一样的，都是5个

2.2.4 fork.c具体的fork函数

我们接下去看看

kernel-3.18/kernel/fork.c

接着刚才的SYSCALL_DEFINE5(clone，接下去调用的是do_fork=>

SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,

int __user *, parent_tidptr,

int __user *, child_tidptr,

int, tls_val)

{

return do_fork(clone_flags, newsp, 0, parent_tidptr, child_tidptr);

}

do_fork函数是实际fork进程的地方，里面包含copy_process拷贝父进程的相关信息、唤醒子进程wake_up_new_task、返回子进程的进程pid值=>

long do_fork(unsigned long clone_flags,

unsigned long stack_start,

unsigned long stack_size,

int __user *parent_tidptr,

int __user *child_tidptr)

{

struct task_struct *p;

...

//通过copy_process，将父进程的信息全部拷贝一份到子进程，还会指定子进程开始运行的位置

p = copy_process(clone_flags, stack_start, stack_size,

child_tidptr, NULL, trace);

...

if (!IS_ERR(p)) {

...

//get_task_pid拿的值也是task->pids[PIDTYPE_PID].pid，这个在init_task_pid有传递给

//task_struct，这些讲的都是上面copy_process创建的pid

pid = get_task_pid(p, PIDTYPE_PID);

nr = pid_vnr(pid);//这个就是进程id值

...

wake_up_new_task(p);//唤醒子进程，将子进程推入调度队列中

...

return nr;

}

到这里返回值nr就是父进程传递给上层的进程号(pid)。do_fork这个函数完整的执行过程只会在父进程运行，子进程不会进入do_fork这个代码的任何一个位置，pid_vnr用来获取子进程的pid并且返回=>

pid_t pid_vnr(struct pid *pid)

{

return pid_nr_ns(pid, task_active_pid_ns(current));

}

pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns)

{

struct upid *upid;

pid_t nr = 0;

//ns->level,pid->level都是0，pid是copy_process创建的，下面会讲到

if (pid && ns->level <= pid->level) {

upid = &pid->numbers[ns->level];//在copy_process的alloc_pid时传递的是父进程命名空间

if (upid->ns == ns)//命名空间的指针是一样的

nr = upid->nr;//但是pid是alloc_pid时新建的

}

return nr;

}

上述父进程的分析已经完了，父进程就是返回自己的pid。关于子进程的返回，我们不得不看一下copy_process的内容，这个函数将会把父进程的相关信息都拷贝一份到子进程中=>

static struct task_struct *copy_process(unsigned long clone_flags,

...

//新建一个task_struct，用于存放子进程的数据

p = dup_task_struct(current);

...

//调度相关的初始化，设置子进程状态TASK_RUNNING，分配CPU

retval = sched_fork(clone_flags, p);

...

//拷贝寄存器相关，此处将设置子进程开始运行的地方

retval = copy_thread(clone_flags, stack_start, stack_size, p);

...

if (pid != &init_struct_pid) {

retval = -ENOMEM;

pid = alloc_pid(p->nsproxy->pid_ns_for_children);//为子进程分配pid，与其命名空间

}

...

设置子进程的pid

p->pid = pid_nr(pid);

...

init_task_pid(p, PIDTYPE_PID, pid);//设置子进程task_struct中PIDTYPE_PID的值是上面创建的pid

...

return p;//返回拷贝的子进程task_struct

}

跟子进程返回相关的函数copy_thread拷贝寄存器相关时在proces.c中

代码位置kernel-3.18/arch/arm64/kernel/proces.c

2.2.5 proces.c的copy_thread

我们接下去看看copy_thread

int copy_thread(unsigned long clone_flags, unsigned long stack_start,

unsigned long stk_sz, struct task_struct *p)

{

struct pt_regs *childregs = task_pt_regs(p);//拷贝寄存器

...

*childregs = *current_pt_regs();

childregs->regs[0] = 0;//一般寄存器0对于返回函数代表的是返回值，此处fork返回值是0

...

//设置pc指针，这个代表的是进程运行CPU指针，也就是子进程开始运行的地方是ret_from_fork

p->thread.cpu_context.pc = (unsigned long)ret_from_fork;

//设置sp，传递寄存器相关值到sp，如子进程fork的返回值就包含在里面

p->thread.cpu_context.sp = (unsigned long)childregs;

...

}

至于ret_from_fork这个函数就没有必要看进去了。

子进程在do_fork的wake_up_new_task以后开始进入调度队列的列表中，一开始执行的地方就是ret_from_fork，不会运行do_fork的任何代码，至于返回值是直接设定为0.

到这里基本上从上到下的调用关系澄清，后续有相关底层调用可以直接搜索底层函数，没有必要再次查看流程，一般搜索方式是 =>

grep -rn "(clone," .

其中clone是你要搜索的函数名字，如你要搜索sys_clone，那么可以直接使用上述指令