本文讲的是调用流程,如何找到相应代码位置,更多的是一种分析代码的方式。
此处将从ZygoteInit调用Zygote.forkSystemServer函数开始跟踪代码直到fork根据父进程和子进程返回pid为止,这会是从上到下的一条简单而通用的例子。
本文的代码是基于Android O的MR0进行分析(kernel仍然是kernel-3.18),MR1正式释放要等到11月吧(kernel google建议是kernel-4.4)
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
Android到bionic,我认为是都属于Android的一部分。
private static boolean startSystemServer(String abiList, String socketName, ZygoteServer zygoteServer)
...
/* Request to fork the system server process */
pid = Zygote.forkSystemServer(
public static int forkSystemServer(int uid, int gid, int[] gids, int debugFlags,
...
int pid = nativeForkSystemServer(
...
//此类函数会注册到虚拟机中
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();
int fork() {
....
int result = clone(nullptr,
....
好了到这里第一部分暂时讲完了,Android如果需要和kernel通信,一般都是需要经过bionic的,如果后续大家看到类似linux的函数可以先在bionic找找,当然你也可以直接在kernel代码中找(如果不关注这些流程,这个会更快,一般这类流程看一遍知道了就不会再看了)
接下来需要讲解的是从bionic到kernel的系统调用,还是接着上面的clone函数讲解
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
...
//kernel-3.18/arch/arm64/include/asm/unistd32.h
__SYSCALL(__NR_clone, sys_clone)
具体定时在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开通的函数,那它跑去哪里了呢?
//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
我们接下去看看
接着刚才的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中
我们接下去看看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,那么可以直接使用上述指令