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，那么可以直接使用上述指令