编译操作系统时system calls未定义，编译器如何运行？

首先要明确核心区别：用户态程序的内存分配依赖系统调用，而操作系统内核本身的内存分配完全不需要调用系统调用——因为内核就是系统调用的提供者。

下面拆解你的疑问：

1. 内核里没有“依赖系统调用的malloc” #

用户态的malloc/calloc之所以要调用系统调用（比如brk或mmap），是因为用户态程序没有直接操作物理内存的权限，必须请求内核帮忙。但内核本身拥有最高权限，它的内存分配函数（比如Linux的kmalloc、vmalloc）是完全独立实现的，直接对接物理内存管理模块，根本不需要走系统调用流程。

2. 编译OS源码时的特殊处理 #

编译内核代码不会使用普通的用户态C标准库（比如glibc），而是用内核自带的极简C库子集，或者直接在编译时禁用标准库依赖。这些内核库函数都是从头实现的，比如内核版的memcpy、printf，都不依赖任何系统调用，直接用C或汇编操作内存、硬件寄存器。

举个例子：Linux内核的内存分配核心是Buddy系统和Slab分配器，这些代码完全用C编写，加上少量汇编处理原子操作或硬件相关逻辑，编译时直接链接内核自己的目标文件，和用户态标准库完全无关。

3. 汇编例程的角色 #

内核里确实会用到汇编，但不是用来“成为系统调用”，而是处理C语言无法直接完成的底层操作：

• 初始化阶段的页表设置、特权级切换
• 内存操作中的原子指令（比如实现内存块的无锁管理）
• 访问CPU特殊寄存器（比如控制内存权限的CR3寄存器）
  这些汇编代码是内核底层逻辑的一部分，不是为了模拟系统调用——内核本身不需要调用自己提供的系统调用接口。

总结 #

编译OS源码时，编译器不需要处理“未定义的系统调用”，因为内核代码从一开始就不会依赖系统调用。内核的内存分配、字符串处理等基础功能，都是内核自己用C+汇编实现的底层逻辑，完全独立于用户态的标准库和系统调用机制。

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