难度：★★本文首发于我的嵌入式技术号「OneChan讲Soc嵌入式」，未经授权禁止转载。在启动文件或链接脚本里，你可能会看到这样的语法：PROVIDE __heap_base = Image$$ARM_LIB_HEAP$$Base; PROVIDE __heap_limit = Image$$ARM_LIB_HEAP$$Limit;或者：PROVIDE __initial_sp = 0x20010000;PROVIDE。字面意思是“提供”。但它不是普通的提供。它提供的是一个可以被用户覆盖的符号。为什么需要这种“弱提供”？什么样的符号需要被提供，但又允许被推翻？今天这篇文章，就来拆开PROVIDE背后的设计哲学。它的答案，牵出了链接器符号解析的优先级规则，以及嵌入式工具链“约定优于配置”的终极体现。一、先看一个真实场景：堆的边界怎么定？假设你正在写一个 Cortex-M3 工程，用了 ARM 的标准 C 库。库里的malloc函数需要知道堆从哪开始、到哪结束。这些信息由两个符号提供：__heap_base和__heap_limit。但问题来了：谁来定义这两个符号的值？/
难度：★★本文首发于我的嵌入式技术号「OneChan讲Soc嵌入式」，未经授权禁止转载。在启动文件或链接脚本里，你可能会看到这样的语法：PROVIDE __heap_base = Image$$ARM_LIB_HEAP$$Base; PROVIDE __heap_limit = Image$$ARM_LIB_HEAP$$Limit;或者：PROVIDE __initial_sp = 0x20010000;PROVIDE。字面意思是“提供”。但它不是普通的提供。它提供的是一个可以被用户覆盖的符号。为什么需要这种“弱提供”？什么样的符号需要被提供，但又允许被推翻？今天这篇文章，就来拆开PROVIDE背后的设计哲学。它的答案，牵出了链接器符号解析的优先级规则，以及嵌入式工具链“约定优于配置”的终极体现。一、先看一个真实场景：堆的边界怎么定？假设你正在写一个 Cortex-M3 工程，用了 ARM 的标准 C 库。库里的malloc函数需要知道堆从哪开始、到哪结束。这些信息由两个符号提供：__heap_base和__heap_limit。但问题来了：谁来定义这两个符号的值？/
