前言：
概括：
Arm32也是通过load_elf_binary加载被 gcc-arm-linux-gnueabi编译的C Main Demo。同样是也是通过ret_from_fork调用kernel_Init来调用elf_load_binary来操纵elf文件的。这点可以看下堆栈：
* thread #1, stop reason = breakpoint 1.1
* frame #0: 0x802fbc0c vmlinux`load_elf_binary(bprm=0x811cd000 at binfmt_elf.c:824:1
frame #1: 0x8028eeb0 vmlinux`bprm_execve at exec.c:1735:12
frame #2: 0x8028ee38 vmlinux`bprm_execve at exec.c:1776:9
frame #3: 0x8028edf4 vmlinux`bprm_execve at exec.c:1845:11
frame #4: 0x8028ecd8 vmlinux`bprm_execve(bprm=0x811cd000, fd=-100, filename=0x81160000, flags=0 at exec.c:1807:12
frame #5: 0x8028f644 vmlinux`kernel_execve(kernel_filename=<unavailable>, argv=0x80c07714, envp=0x80c077a0 at exec.c:2006:11
frame #6: 0x8083d8d8 vmlinux`run_init_process(init_filename=<unavailable> at main.c:1438:9 [artificial]
frame #7: 0x80847010 vmlinux`kernel_init(unused=<unavailable> at main.c:1534:9
frame #8: 0x80100130 vmlinux`ret_from_fork at entry-common.S:146
同样x64和Arm32的用户态入口也是Glibc的_start函数。
那么不同点在哪儿呢？上说过x64设置IP和SP的是start_thread，而Arm32里面则是START_THREAD这个宏定义来设置IP和SP，实质上做的东西是一样的，但是代码不一样，他们都是通过返回到ret_from_fork，然后获取到被设置的regs变量，里面包含了被start_thread OR START_THREAD宏设置的IP和SP。
看下START_THREAD宏定义：
#define START_THREAD COMPAT_START_THREAD
#define COMPAT_START_THREAD(ex, regs, new_ip, new_sp \
compat_start_thread(regs, new_ip, new_sp, ex->e_machine == EM_X86_64
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp, bool x32
{
start_thread_common(regs, new_ip, new_sp,
x32 ? __USER_CS : __USER32_CS,
__USER_DS, __USER_DS;
}
static inline void start_thread_common(struct pt_regs *regs, unsigned long pc
{
s32 previous_syscall = regs->syscallno;
memset(regs, 0, sizeof(*regs;
regs->syscallno = previous_syscall;
regs->pc = pc;
if (system_uses_irq_prio_masking(
regs->pmr_save = GIC_PRIO_IRQON;
}
最后的start_thread_common设置了PC也就上面的IP。Glibc库的入口_start函数。这一点也可以验证下：
arm-linux-gnueabi-gcc -static -o hello hello.c
readelf -s hello
3127: 00010418 0 FUNC GLOBAL DEFAULT 4 _start
在以下地方下断点
linux-source-5.15.0版本b binfmt_elf.c：1325也可以br s --file binfmt_elf.c --line 1325
c运行到此处，在c几次让START_TRHEAD宏运行完
如下：
p/x *regs
(pt_regs $7 = {
uregs = {
[13] = 0x7e952f10
[14] = 0x00000000
[15] = 0x00010418
[16] = 0x00000010
[17] = 0x00000000
}
我们看到[15]=后面就是10418,也就是上面Glibc的入口_start函数。
结尾：
ret_from_fork是否同xx64一样被_schedule和schedule调度。
Arm32的_start调用是否也是缺页异常。
关于这两点下篇再看看。