做单片机底层开发的人，迟早会被一个现象逼到怀疑人生：单任务裸机程序跑得稳如泰山，一旦套上 RTOS，printf 开始乱串行、malloc 偶发崩溃、errno 毫无规律跳变。我第一次遇到这些问题时以为是自己代码写错了，排查了整整一周，最后揪出来的真凶，竟然是平时压根不被注意的C 库运行时——以及它背后那块不起眼的状态区域，圈内通常叫它libspace。
这篇就聊聊这个话题：libspace 是什么、为什么多任务之后它就成了定时炸弹、以及怎么从根上解决中断和任务并发时的安全问题。适合正在从裸机过渡到 RTOS、或者被系统性 bug 折磨的兄弟们参考。
1. 从链接脚本说起：C库运行时到底装在哪个“房间”里
1.1 你写的 main() 背后，链接脚本在做哪些分配
很多开发者对链接脚本的态度是“能跑就行”，打开默认模板看一眼注释就关掉了。但实际上，你在裸机上的每一次函数调用、每一个全局变量，最终都是靠链接脚本把目标文件里的段（section）按照地址摆放好，才真正落地到芯片的 Flash 和 RAM 里。
拿常见的 ARM Cortex-M 工程举例，链接脚本里通常有这几块关键区域：
- Flash：存放只读数据、代码段（.text）和启动向量（.isr_vector）。
- RAM：存放已初始化全局变量（.data）、未初始化全局变量（.bss）、堆（.heap）和栈（.stack）。
启动代码在进入 main() 之前，要干三件事：把 .data 从 Flash 拷贝到 RAM，把 .bss 清零，然后设置好栈指针。很多人不知道的是，在完成这些基本动作之后，C 库自己的初始化代码还会接着干活，比如准备标准 I/O 的缓冲区、初始化 malloc 的空闲链表、设置 errno 的初始值。这一整套“看不见的准备动作”，合起来就是C 库运行时（C runtime）。
你可以把链接脚本想象成给程序“分房间”的物业：Flash 是公共储物间，RAM 是每户人家的卧室，而 C 库运行时则是这栋楼的水电系统——平时没人关心水管怎么走的，但一旦楼里住了好几户人（多任务），水管不够用或者水压互相干扰，整栋楼立刻乱套。
1.2 libspace 的本质：C库全局状态的大本营
如果你翻过 Newlib 这类嵌入式 C 库的源码，会在 reent 目录下找到一个叫 libspace.c 的文件，里面定义了整个 C 库运行时最核心的全局状态：
static struct _reent impure_data = _REENT_INIT(impure_data); struct _reent *_impure_ptr = &impure_data;这段代码看着不起眼，但它定义了两个东西：一个_reent结构体实例impure_data，以及一个指向它的全局指针_impure_ptr。_reent结构体就是 libspace 的核心，它把 C 库运行时的“可变全局状态”全部收纳在一起。
这个结构体里面有什么？我总结一下关键字段：
- errno：最后一个错误码，标准库很多函数靠它向调用方传递错误信息。
- 标准 I/O 流指针：
stdin、stdout、stderr的文件控制块，对应底层设备的读写缓冲区。 - locale 相关的全局设置：字符集、区域格式等。
- 临时文件记录：
tmpnam这类函数依赖的状态。 - 随机数状态：
rand()使用的种子和辅助变量。
这些状态是 C 标准库在单线程时代留下的“遗产”：编译器假设进程内只有一个执行流，所以全局变量随便用，不用担心别人来抢。
问题的种子，从这时候就已经埋下了。单任务裸机环境里，整个程序确实只有一个执行流，_impure_ptr指向唯一一份impure_data，所有全局状态天然“安全”。但一旦你引入多任务，情况就完全不同了——每个任务都是独立的“执行流”，它们共用同一个_impure_ptr、同一份 errno、同一组 I/O 缓冲区。两个任务同时调用printf，输出缓冲区立刻互相踩踏；任务 A 刚刚设置完 errno，任务 B 还没来得及读取，errno 就被任务 C 覆盖了。这类 bug 看起来像是随机出现的，实际上是因为“共享状态”只属于单执行流假设下的产物。
1.3 单任务世界的“和平假象”是怎么维持的
很多人裸机开发好几年，从没碰过 libspace 这个概念，觉得它离自己很远。这其实是一种“和平假象”：裸机主循环本质上是一个无限循环，这个循环就是唯一的执行流，任何函数调用都是串行执行的，不存在“同时访问”这回事。
举个例子，你写printf("temp: %d\n", adc_value)时，printf 会往全局的 stdout 缓冲区里写数据，写完再统一刷到串口。整个过程是原子的吗？在单任务里根本不需要“原子”概念，因为没人会在你写了一半的时候插进来改数据。
但你把这段代码放到 RTOS 的多个任务里，假设任务 A 和任务 B 都往同一个串口打印日志，如果 C 库实现没有加锁，任务 A 写到一半，调度器切到任务 B，任务 B 又往同一个缓冲区里写，最后串口吐出来的就是你看到的乱码——不是硬件问题，是软件层面共享缓冲区的竞争。
理解了这层“和平假象”，你就知道为什么多任务环境下首先要处理的是 C 库运行时，而不是业务逻辑。业务逻辑上的 bug 往往有迹可循，C 库运行时的问题却像幽灵，因为你根本没有在代码里显式写过这些全局状态，排查时天然会忽略它们。
2. 多任务一上来就翻车：谁动了我的 errno 和 printf
2.1 _reent 与 _impure_ptr：线程状态的核心枢纽
前面说了，libspace 的核心是一个_reent结构体，而访问这个结构体的入口就是全局指针_impure_ptr。在标准 C 库内部，几乎所有可能修改全局状态的函数，都会经过一个宏来拿到当前执行流对应的_reent指针，比如：
int strtol(const char *restrict nptr, char **restrict endptr, int base) { struct _reent *ptr = _REENT; ... if (错误) { ptr->_errno = ERANGE; } }这里_REENT宏最终展开就是对_impure_ptr的解引用。单任务下，_impure_ptr始终指向同一个_reent实例，一切正常。多任务下，任务切换时如果_impure_ptr没有跟着切换，就会出问题：
- 任务 A 执行
strtol，设置 errno = 0 并在自己的逻辑里判断返回值。 - 任务切换，任务 B 也执行
strtol，把 errno 改成了 ERANGE。 - 任务 A 恢复运行，检查 errno 发现是 ERANGE，误以为自己上次调用出错了。
这种 bug 的恶心之处在于：代码逻辑在单任务下完全正确，编译也不报错，多任务下却时好时坏，而且一旦出错，定位范围特别大。你很难想到是 errno 被“邻居”任务改了。
解决思路其实很直接：让每个任务拥有自己的_reent实例，并在任务切换时让_impure_ptr指向当前任务的实例。这就是“per-task reentrancy”的基本思想，也是很多 RTOS 集成 C 库时做的核心工作。
2.2 三种可重入改造方案对比
实现 per-task reentrancy 的工程方案，我总结下来主要有三种，各有取舍：
| 方案 | 实现思路 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|---|
| 方案 A：任务控制块内嵌 _reent 实例 | 把_reent结构体直接放进任务控制块（TCB），任务创建时初始化，切换时同步切换_impure_ptr | 分配简单，生命周期与任务一致，不需要额外内存池管理 | TCB 会变大，且结构体定义要暴露给任务管理模块 | 任务数量固定的中小型项目 |
| 方案 B：运行时动态分配和释放 | 任务创建时malloc一块_reent，任务删除时释放 | 不浪费空间，任务数量灵活 | 依赖 malloc，而 malloc 本身在多任务环境需要先保证线程安全，存在循环依赖 | 任务动态创建/删除频繁的复杂系统 |
| 方案 C：封装一层库函数包装层 | 不修改 C 库，对外提供安全版本的函数，在函数内部加锁或使用任务本地状态 | 对上层代码透明，库升级方便 | 工作量大，要包装的函数太多（printf、malloc、strtok 等），且容易漏 | 使用厂商闭源 C 库，无法修改内部实现时 |
实际项目里最推荐先做方案 A，因为它最干净、最可控。很多 RTOS 内核已经把这一步做成了可选配置，你只需要打开对应的编译开关。如果条件不允许修改 TCB，再考虑方案 C，用互斥量把关键函数包一层。
我印象最深的一个项目里，开发团队为了省 RAM，把任务数量压得很紧，每个任务栈 1KB。一开始用了方案 B，结果任务创建时先 malloc、malloc 又依赖锁、锁又依赖内核初始化……整个初始化顺序乱成一锅粥。后来改成方案 A，任务数量写死、TCB 静态分配，问题直接消失。嵌入式系统里，静态分配永远是比动态分配更稳的选择，这个原则在 C 库运行时这里同样适用。
2.3 malloc 与堆：多任务下最容易踩的坑
malloc/free 是另一个重灾区。绝大多数嵌入式 C 库的 malloc 实现，都是基于一个叫sbrk的底层接口，它做的事情很简单：把堆区的边界指针往后拨，返回一块新的空闲地址。malloc 内部维护一个空闲链表，分配时遍历链表找合适大小的块，释放时把块插回链表，必要时做合并。
问题很明显：空闲链表的头指针，又是一个全局状态。任务 A 和任务 B 同时调用 malloc，如果链表操作没有锁保护，两个任务可能同时修改同一个节点的next指针，轻则内存碎片，重则直接覆盖已分配块的数据。这种 bug 引发的问题非常隐蔽：可能运行几小时后才随机崩溃，而且现场难以复现。
解决方法不外乎两种：
- 给 malloc/free 加上互斥锁。这是最标准的做法，注意锁的粒度要覆盖整个空闲链表操作过程。如果用 RTOS 封装好的
vPortMalloc之类的接口，大部分已经内置锁了，直接用就行。 - 中断中禁止 malloc/free，业务层统一规避。malloc 的实现往往不是可重入的，即便加了锁，中断里调用
vPortMalloc也可能因为锁被普通任务持有而卡死。我给自己定的铁律是：中断服务函数里一律不用堆分配函数，需要传递数据给任务时，用预先分配好的固定缓冲区。
还要注意一点：malloc 依赖的堆区大小由链接脚本决定。很多新手在链接脚本里只给了 1KB 堆，出门在外跑着跑着内存不够，malloc 返回 NULL，代码没做校验，接着往下写，就产生“随机崩溃”。排查这类问题，先把链接脚本里的堆区大小、空闲 RAM 总量和实际消耗量算清楚，再动手改代码。
3. 中断安全：在 ISR 里调用 C 库函数的边界在哪里
3.1 可重入与中断安全的区别
很多人把“可重入”和“中断安全”混为一谈，实际上有本质差别。一个可重入函数，意味着函数体内的所有状态都来自参数和栈，不依赖全局变量，可以同时被多个执行流调用而不出问题。而中断安全，则要求函数在中断上下文里被调用时，不会破坏主程序的任何状态。
举一个例子：memcpy是纯内存操作，只要不涉及重叠拷贝，它就是天然可重入的，在中断里调用也没问题。memcpy的实现不会修改任何全局标志。但rand()就不一样，它内部维护一个全局种子，每次调用都会修改这个种子，所以它是不可重入的——两个任务同时调用rand()，返回同样的序列，状态互相覆盖；在中断里调用rand()，则可能把主任务刚刚计算到一半的随机序列搞乱。
搞清楚这个概念后，很多问题就清晰了。在 ISR 里使用 C 库函数，核心原则是：只调用纯粹基于栈和参数的函数，不调用修改全局状态的函数。
让我给你一个我长期在项目里使用的中断安全 C 库函数参考清单（基于常见嵌入式 C 库实现，具体以你的库为准）：
| 类型 | 中断中安全调用 | 中断中禁止调用 |
|---|---|---|
| 内存操作 | memcpy、memset、memmove、memcmp | — |
| 字符串处理 | strlen、strcpy、strcmp、strchr（不设 errno 的版本） | strtok（内部保存剩余字符串指针） |
| 数字转换 | 自己写的整数转 ASCII 函数 | sprintf、snprintf、sscanf（内部依赖全局 I/O 和 errno 状态） |
| 数学运算 | 纯整数运算 | rand、srand（全局种子）、浮点运算（涉及软浮点状态） |
| 堆操作 | — | malloc、free、realloc（非可重入） |
3.2 中断与任务间的 errno 冲突
中断里最容易踩的暗雷其实是 errno。很多看似纯计算的函数，内部出错时仍然会设置 errno。比如strtol在做字符串转换时，如果遇到超出范围的数字，会设置 ERANGE。如果在中断里调用strtol，且中断发生在任务 A 刚好设置完 errno、还没来得及处理的时间窗口，那么任务 A 的 errno 会被中断里的strtol覆盖。
这个冲突要怎么处理呢？我的习惯是：
- 中断内避免调用任何可能设置 errno 的函数。对于字符串转数字、数学库这类操作，自己写一个不依赖全局 errno 的版本。
- 如果实在无法避免，则在进入中断时保存
_impure_ptr，中断结束前恢复。但注意中断内修改_impure_ptr本身也必须小心，如果中断嵌套，还要额外管理多层保存。 - 尽量不要在中断里做复杂计算。ISR 应该只负责“搬数据”和“置标志”，真正的处理逻辑放到任务里做。这句话被说了无数遍，但确实是每次踩坑之后才会真正服气。
所谓“一个工程师的成长，是踩坑踩出来的”，很多人在中断里调用的sprintf并不是不能用，而是你根本无法保证所有执行路径都安全。中断里放一个几微秒的函数调用，看起来节约了任务时间，实际可能埋了一颗定时炸弹。
3.3 临界区与原子操作：保护共享状态的正确姿势
中断服务和普通任务之间，以及多个中断之间，对共享变量的访问同样需要保护。保护手段按优先级从低到高有这么几档：
- 关中断（
__disable_irq()）：把整个系统所有可屏蔽中断都关掉，简单粗暴。缺点是不能长时间占用，否则实时性就废了。用在临界区非常短的场合，比如原子地修改一个 32 位变量。 - 临界区嵌套保护：用一个计数器或者保存 PRIMASK 的方式支持嵌套关中断，保证退出时恢复到进入前的状态。比如：
uint32_t primask; primask = __get_PRIMASK(); __disable_irq(); /* 临界区代码 */ __set_PRIMASK(primask);- 互斥量 + 关中断：在任务间用互斥量，在中断和任务之间用关中断或原子操作。因为中断里拿互斥量容易死锁，任务拿互斥量时则可能被调度阻塞，所以不同场景用不同的锁。
- 原子操作指令：ARM 提供
LDREX/STREX之类的指令，或者直接用__atomic_*内建函数，硬件保证操作的原子性，连关中断都不用。
实际操作里，我倾向于“能原子就不关中断，能关短中断就不上锁”。举个例子，一个 32 位的共享计数器，主任务累加、某定时器中断清零，那么累加和清零用原子操作就够了；如果共享的是一个结构体，无法用一条原子指令搞定，那就必须关中断保护整个操作过程。
注意一点，volatile只解决编译器优化导致的可见性问题，根本不能替代锁或原子操作。很多人以为加个volatile就“多线程安全”了，这个误解在嵌入式领域尤其危险。volatile告诉编译器“别优化这个变量”，但硬件层面的读写可能被拆成多条总线事务，读者读到一半的数据照样是不一致的。
4. 实操：一个最小 RTOS 项目的完整配置示例
4.1 链接脚本中的内存划分与 libspace 区域
理论说了一堆，没有实操都是空谈。我拿一个模拟项目 X 举例，它是一台双任务数据采集设备：任务 A 负责周期性采集 ADC 并打印日志，任务 B 负责通过串口通信处理指令。还挂了一个 UART 接收中断。这个项目使用的内核是一个轻量级 RTOS，支持任务创建、延迟和互斥量。
第一步是配置链接脚本。下面是这个项目使用的简化版 ARM Cortex-M 链接脚本，重点看 RAM 里的分工：
MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K } _estack = ORIGIN(RAM) + LENGTH(RAM); SECTIONS { .isr_vector : { KEEP(*(.isr_vector)) } > FLASH .text : { *(.text*) *(.rodata*) } > FLASH .data : { _sdata = .; *(.data*); _edata = .; } > RAM AT> FLASH .bss : { _sbss = .; *(.bss*); _ebss = .; } > RAM /* 堆区大小固定为 8KB */ . = ALIGN(8); .heap : { _heap_start = .; . = . + 8K; _heap_end = .; } > RAM /* 剩余 RAM 全部作为系统栈 */ . = ALIGN(8); _sys_stack_start = .; } > RAM这里面几个要点：
- libspace 的落点在 .bss 段。因为
impure_data是静态变量，链接器会把它放到 .bss 里，启动代码清零 .bss 时就把它的内容初始化和重置好了。 - 堆区专门划了 8KB。malloc 的空间从这里出。如果你的业务里大量使用动态内存，先把这里调宽；但别无脑调大，嵌入式 RAM 总共就那么大，堆占多了，任务栈可能分配不出来。
- 栈区是所有任务栈拼在一起的。裸机里整个 CPU 用一套栈，RTOS 里每个任务各有一块栈区域，链接脚本只划出一个总的可分配范围，任务创建时从这块区域里划分。
链接脚本写完后，启动代码要保证把_heap_start和_heap_end这两个符号传给 C 库的堆管理模块。在 Newlib 里对应的是_sbrk_r这个低层函数：
void *_sbrk_r(struct _reent *r, ptrdiff_t incr) { extern char _heap_start[], _heap_end[]; static char *heap_end = _heap_start; char *old_heap; char *new_heap; old_heap = heap_end; new_heap = heap_end + incr; if (new_heap > _heap_end) { r->_errno = ENOMEM; return (void *)-1; } heap_end = new_heap; return old_heap; }这个函数维护了一个局部静态指针heap_end，每次调用把指针往后“拨”incr个字节，返回旧地址。看到这里你就明白了：heap_end又是一个全局共享状态。多任务并发 malloc 时，两个任务同时取下同一个heap_end，各自返回同一块内存，数据互相覆盖。所以要给整个堆管理过程加锁，而不能只靠这里判断越界。
4.2 任务级 reent 初始化的核心代码
链接脚本配好后，第二步是在内核的任务控制块里挂上_reent。下面是我在实际项目里用的精简模式：
/* 任务控制块结构，挂载 C 库重入上下文 */ typedef struct { uint32_t *sp; /* 栈指针（由切换代码维护） */ struct _reent reent; /* 每个任务独立的 C 库运行时状态 */ void *stack_top; /* 栈顶地址 */ void *stack_base; /* 栈底地址 */ int prio; } TCB_t; /* 任务创建函数 */ void task_create(TCB_t *tcb, task_func_t func, void *arg, uint32_t *stack, uint32_t stack_size, int prio) { tcb->stack_top = (void *)((uint32_t)stack + stack_size); tcb->stack_base = stack; tcb->prio = prio; /* 关键：初始化任务自己的 _reent 结构 */ _REENT_INIT(&tcb->reent); /* 初始化任务上下文，并将入口函数入栈 */ init_task_stack(tcb, func, arg); } /* 任务切换时，拿出下一个任务的 reent 指针 */ void task_switch_to(TCB_t *next) { _impure_ptr = &next->reent; /* 恢复 next->sp，完成上下文切换 */ restore_context(next->sp); }_REENT_INIT是 C 库提供的一个初始化宏，会把结构体内的 errno、标准流指针等清成默认值。每个任务创建时调用它，就能获得一份独立、干净的状态。
注意一点：第一个任务（通常是 main 任务）的_impure_ptr指向的应该是 main 对应的_reent实例。启动代码里_impure_ptr默认指向impure_data，也就是 libspace.c 里那个静态实例，在单任务模式下完全够用。进入多任务模式后，第一个被调度的任务要覆盖一次_impure_ptr。我踩过的坑是：main 任务创建完后直接修改_impure_ptr，但没有在切换前保存 main 自己的 reent 指针，导致后续切回 main 时_impure_ptr还是别的任务的，main 的 printf 输出全部乱掉。
4.3 验证与实测：如何判断改造是否成功
配置完代码，你肯定要验证多任务并发这块改造到底行不行。光靠“看起来没崩”是不算的，我一般做三件事：
第一件：压力测试并发打印。让两个任务各自循环打印不同前缀的字符串，比如任务 A 打"A"，任务 B 打"B"，跑一晚上，串口输出里如果出现“AA BB”这种连续性错乱，说明 stdout 缓冲区还有竞争。这里有个小细节：串口驱动本身的输出没做好互斥，也会导致乱码，所以要确认是 C 库层面的问题还是外设驱动层面的问题。一个简单办法是临时把 C 库输出重定向到内存缓冲区，再周期性导出到上位机，如果内存里数据完整，说明 C 库这边没问题，问题在串口驱动的输出函数。
第二件：长时间运行观察堆损坏。业务逻辑里构造大量动态内存分配和释放的测试用例，运行 72 小时以上。如果堆空闲链表被破坏，通常表现为偶发的双重释放、野指针或者内存泄漏。建议在 mcu 里实现一个简单的堆使用量统计函数，定期上报，看它是否单调增加——单调增加基本上就是泄漏了。另外，_sbrk_r返回错误时，要能在日志里看到“ENOMEM”相关记录，别等系统 FPU 异常（HardFault）了才去查。
第三件：硬故障中断抓现场。如果系统有看门狗，先临时关掉，让故障直接死在现场。HardFault 的寄存器现场保存在栈里，用调试器连上，看一眼故障地址，再和 hex 文件里的符号表比对，往往能直接定位到是 malloc 空闲链表被覆盖后，某次 free 走到了非法分支。
5. 常见问题与排查技巧实录
下面这些问题，全是我在这些年的项目里真实遇到过、并且最终靠“追 C 库运行时”才解决的。我整理成速查表，方便你遇到类似现象时对照排查：
| 故障现象 | 可能原因 | 排查方法/解决方案 |
|---|---|---|
| 多任务下 printf 输出乱码 | stdout 缓冲区缺少互斥保护 | 确认 _impure_ptr 切换是否随任务切换执行；给串口输出函数加互斥锁；确认库和内核是否开启重入配置 |
| errno 值在任务间“穿越” | 任务切换时 _impure_ptr 未同步 | 在任务切换函数里显式赋值 _impure_ptr；用调试器在两个任务里分别打印 _impure_ptr 地址确认不同 |
| malloc 偶发返回相同地址 | _sbrk_r 里的堆末尾指针竞争 | 给堆分配加锁；确认 sbrk 实现是可重入的，必要时改为每任务独立堆 |
| 中断里调用 sprintf 导致任务数据被改 | sprintf 内部依赖 _impure_ptr 和全局缓冲区 | 中断内改为自定义整数转字符串函数；或进入中断时保存/恢复 _impure_ptr |
| 程序崩溃但看不到业务错误 | 堆越界写坏相邻链表节点 | 开启 Heap 调试宏（如 _MALLOC_STATS）；在崩溃现场遍历空闲链表验证结构 |
| 任务删除后内存慢慢变少 | 任务对应 _reent 结构未释放 | 检查任务删除的清理逻辑，是否调用了释放 _reent 的代码；必要时任务复用 |
你可能会注意到，这些问题的排查路径高度一致：先怀疑全局状态，再怀疑互斥保护，最后怀疑内存布局。这不是巧合，C 库运行时本来就是“一堆全局状态 + 一堆核心算法”的组合，多任务环境引入的并发访问，本质上就是把单线程假设下的所有隐藏共享点全数暴露。
还有一个很实用的排查技巧：在任务切换函数里，顺手对_impure_ptr做一次“合理性检查”。比如确认它指向的地址落在合法的 RAM 范围内，或者确认它的_errno初值和上一次见到的不一样。这些检查代码在正式发布时删掉，但在调试期间能帮你在第一现场抓住问题。
现在再聊聊中断安全的一个经验教训。某次开发通信模块时，我在 RX 中断里直接调用sprintf把收到的字节格式化打印到调试串口。这个模块单独测试一切正常，联调时却老出现接收数据丢字节的现象。排查了很久，最终定位到问题：sprintf执行期间会临时占用 stdout 缓冲区，而另一个任务的打印进程同时写这个缓冲区，两边互相覆盖，导致丢失数据。从那以后，我给自己定了一条规矩：中断里只做“最小必要动作”——搬数据、置标志、唤醒任务，凡是超过 10 行逻辑的，一律扔到任务里做。这听起来像是最基础的 RTOS 常识，但真正被坑过的人才会把它刻进骨子里。
另外一个实用的建议是：在启动阶段，打印出 C 库运行时各关键结构的地址，比如_impure_ptr的地址、堆区的heap_start和heap_end。打印一次之后，你在调试器里看到这些地址会对排查有很大帮助，至少知道当前代码是否已经跑到了正确的初始化流程里。
最后再分享一个小技巧
如果你用的是基于 Newlib 的交叉编译工具链，在链接时留意一下编译器自动链接了哪些重入相关的符号。比如_impure_ptr是外部定义的，那么全局搜索一下它到底从哪里来。如果发现链接进了libc.a的某个库函数，说明你用的库已经支持了重入特性，那就只需要在任务切换时正确赋值即可。如果链接完发现根本没有_impure_ptr这个符号的引用，那你的 C 库可能是精简版，很多重入功能没有启用，这时就要考虑自己实现一套轻量级安全封装。这个检查做一次，能省下后面好几天排查时间。
C 库运行时这个东西，平时看不见摸不着，它不像中断向量表那样给你清晰的入口，也不像驱动接口那样有明确的 API。它更像是地基里的钢筋——楼层不高时没人注意，但一旦要多任务，钢筋规格就得重新核算。希望这篇文章能帮你在下一次遇到“诡异随机 bug”时，少走几条弯路，直接想到去查那块小小的 libspace。
