兄弟，我来给你拆解下64位Linux内核启动32位ELF进程的关键差异，你看binfmt_elf.c的时候大概率没抓到这些分散在代码里的核心分支：

1. ELF头部的模式识别分支 #

内核在load_elf_binary函数里做的第一件事就是解析ELF头部的e_ident[EI_CLASS]：

• 如果是ELFCLASS32，会立刻切换到32位专属的处理逻辑，比如用elf32_ehdr结构体解析头部，而非默认的64位elf64_ehdr。
• 同时会检查elf_flags里的架构兼容标记（比如x86_64的EF_MACHINE32），确认内核是否开启了32位兼容支持（比如CONFIG_IA32_EMULATION）。

2. 进程地址空间的限制与初始化 #

• 64位进程默认使用完整的64位虚拟地址空间，而32位进程会被限制在低4GB地址范围（不同架构可能有微调）。内核初始化进程地址空间（mm_struct）时，会设置mm->context里的兼容模式标记，让MMU切换到32位地址翻译模式。
• 你可以留意setup_new_exec函数里针对32位进程的地址空间初始化分支，这里会覆盖默认的64位地址布局。

3. 寄存器上下文的专属初始化 #

创建进程的最后一步是设置用户态寄存器上下文，这里的差异非常明显：

• 对于32位进程，内核会调用架构专属的32位启动函数，比如x86架构下的start_thread32，它会把ELF入口地址放到32位指令指针%eip，栈指针设置为%esp，同时配置段寄存器为32位兼容模式（比如CS段的RPL位）。
• 而64位进程用的是start_thread，操作的是%rip和%rsp这些64位寄存器。

4. 进程个性（personality）与系统调用兼容层 #

• 加载完32位ELF后，内核会设置进程的personality字段为PER_LINUX32（或对应架构的32位标识），告诉后续内核逻辑（比如系统调用处理、信号处理）这个进程需要32位兼容处理。
• 32位进程发起的系统调用会走专属的兼容入口（比如x86_64的int 0x80而非64位的syscall），内核有独立的32位系统调用表，把32位调用号映射到对应的内核实现。

5. 辅助向量（auxv）的差异化生成 #

内核传给用户空间的辅助向量（在create_elf_tables函数里生成）也会有差异：

• 32位进程的auxv会包含AT_SYSINFO指向32位系统调用入口，以及其他32位专属的环境信息，确保用户态的动态链接器（比如ld-linux.so.2而非64位的ld-linux-x86-64.so.2）能正确工作。

你之前看binfmt_elf.c可能没注意到这些分散在架构相关代码（比如arch/x86/kernel/process.c里的start_thread32）或者配置依赖的分支，这些才是区分32位和64位进程启动的核心。

内容的提问来源于stack exchange，提问作者rubund