- 在上一次的Linux系统调用窥探介绍中，我选取了sys_getpid这个系统调用，这个系统调用比较简单，调用号0X14，除此之外不需要额外的参数传递。
当然，如果确实对参数的传递，ebx、ecx、edx、esi、edi、ebp这几个寄存器究竟是从左到右还是从右到左地存储我们传递的参数，实际上是arg1对应ebx，arg2对应ecx，以此类推。function(arg1, arg2, arg3, arg4, arg5, arg6);
- 由于Linux内核中没有调试器，理论上，如果真的想调试内核的工作过程，需要用更加geek的方法。通过一些强大的第三方工具，如kdb、kgdb对内核打补丁，将这些调试器附加到内核上，就可以完成调试内核的心愿。
调试是软件开发过程中一个必不可少的环节，在 Linux 内核开发的过程中也不可避免地会面对如何调试内核的问题。但是，Linux 系统的开发者出于保证内核代码正确性的考虑，不愿意在 Linux 内核源代码树中加入一个调试器。他们认为内核中的调试器会误导开发者，从而引入不良的修正[1]。所以对 Linux 内核进行调试一直是个令内核程序员感到棘手的问题，调试工作的艰苦性是内核级的开发区别于用户级开发的一个显著特点。
可以看到，我们在sys_getpid处设置了断点。
c运行，由于我们正常的启动流程，系统并不会触发断点。
执行我们想要的程序，因为牵涉到系统调用，故运行到断点处停下。
- 可以看到，系统停在了SYSCALL_DEFINE0(getpid)处，此时，我们不再用n、s进行源码的运行，而是用ni、si运行汇编代码。
si一步一步运行，可以发现，运行到了syscall_exit处：
syscall_exit:
LOCKDEP_SYS_EXIT
DISABLE_INTERRUPTS(CLBR_ANY) # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
TRACE_IRQS_OFF
movl TI_flags(%ebp), %ecx
testl $_TIF_ALLWORK_MASK, %ecx # current->work
jne syscall_exit_work
接下来，代码的运行过程，像是进入了一个混沌世界。
通过跟踪，可以发现，大概系统执行了INTERRUPT_RETURN之后便返回了。
- 有个奇怪的问题，发现我用C语言和用汇编语言写的两份系统调用的特性不太一致，路径不一样。
- C语言写的话，只能第一次在系统中断处停下，如果是汇编，则每次都能在中断处停下。
- 这说明什么呢，C语言的库函数getpid()实现的逻辑我们未知，需要再次发掘。
至于调度点，暂时还未发现。
