WEBKT

别再硬编码地址了：CMake 环境下生成多平台兼容 Linker Script 的自动化方案

58 0 0 0

在嵌入式开发或底层系统编程中，**链接脚本（Linker Script, .ld）**是定义程序内存布局的核心文件。然而，传统的开发模式往往需要为每一个不同的 SoC 变体、不同的内存配置（如 Flash 大小差异）手动维护一份独立的 .ld 文件。

当项目规模扩大，涉及 ARM Cortex-M、RISC-V 等多种架构，或者需要支持多种启动模式（如 QSPI Flash、SRAM 运行）时，维护这些静态脚本会变成一场灾难。本文将分享一种基于 CMake + C 预处理器 (CPP) 的自动化方案，实现链接脚本的动态生成与跨平台复用。

1. 核心思路：从静态到动态

要实现自动化，我们需要打破“链接脚本是静态文本”的固有认知。我们的目标是将链接脚本视为一种“源码”，经过编译/转换后生成最终的产物。

主要分为两个维度：

  1. 参数注入（CMake 层面）：利用 CMake 的 configure_file 动态注入内存起始地址、容量等基础参数。
  2. 逻辑处理（预处理器层面）：利用 C Preprocessor (CPP) 处理复杂的宏开关（如 #ifdef USE_BOOTLOADER），控制段（Section）的包含关系。

2. 第一阶段：创建链接脚本模板

首先，我们将传统的 .ld 文件改为 .ld.in 模板。在模板中使用 CMake 风格的变量占位符 @VARIABLE@。

/* linker_template.ld.in */
MEMORY
{
    FLASH (rx) : ORIGIN = @FLASH_START@, LENGTH = @FLASH_SIZE@
    RAM (rwx)  : ORIGIN = @RAM_START@,   LENGTH = @RAM_SIZE@
}

SECTIONS
{
    .text :
    {
        KEEP(*(.vectors))
        *(.text*)
        *(.rodata*)
        @ADDITIONAL_TEXT_SECTIONS@
    } > FLASH

    .data : AT (ADDR(.text) + SIZEOF(.text))
    {
        _sdata = .;
        *(.data*)
        _edata = .;
    } > RAM
}

3. 第二阶段：CMake 自动化逻辑

在 CMakeLists.txt 中，我们需要根据当前的编译目标（Target）配置这些变量，并触发生成动作。

3.1 定义内存参数

我们可以通过配置文件或 if(BOARD STREQUAL ...) 来设置参数：

# 根据不同板型定义内存分布
if(MCU_MODEL STREQUAL "STM32F407")
    set(FLASH_START 0x08000000)
    set(FLASH_SIZE  "1024K")
    set(RAM_START   0x20000000)
    set(RAM_SIZE    "128K")
elseif(MCU_MODEL STREQUAL "ESP32C3")
    # ESP32 等平台可能有不同的映射逻辑
    set(FLASH_START 0x42000000)
    set(FLASH_SIZE  "4M")
    set(RAM_START   0x4037C000)
    set(RAM_SIZE    "400K")
endif()

3.2 使用 configure_file 进行初步替换

configure_file 会将 @VAR@ 替换为 CMake 中的变量值。

configure_file(
    "${CMAKE_CURRENT_SOURCE_DIR}/linker_template.ld.in"
    "${CMAKE_CURRENT_BINARY_DIR}/generated_linker_step1.ld"
    @ONLY
)

4. 进阶：引入 C 预处理器 (CPP)

有时候，简单的变量替换不足以处理复杂的段合并逻辑。此时，我们可以让编译器先对链接脚本进行“预处理”。

我们可以将模板写成类似 .S 的格式，支持 #include 和 #ifdef。

# 定义预处理命令
add_custom_command(
    OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/final_linker.ld"
    COMMAND ${CMAKE_C_COMPILER} -E -P -x c 
            -I${CMAKE_CURRENT_SOURCE_DIR}/include
            "${CMAKE_CURRENT_BINARY_DIR}/generated_linker_step1.ld" 
            -o "${CMAKE_CURRENT_BINARY_DIR}/final_linker.ld"
    DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/generated_linker_step1.ld"
    COMMENT "Preprocessing linker script..."
)

# 确保目标依赖该生成的 ld 文件
add_custom_target(generate_ld DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/final_linker.ld")
add_dependencies(${PROJECT_NAME} generate_ld)

关键参数解释：

  • -E: 仅运行预处理器。
  • -P: 禁止生成行号标记（Line markers），这对于链接脚本至关重要，否则链接器无法识别。
  • -x c: 强制将输入文件视为 C 语言源码进行处理。

5. 将生成的脚本应用到 Target

生成文件后，我们需要告知链接器使用这个新生成的文件：

target_link_options(${PROJECT_NAME} PRIVATE 
    "-T${CMAKE_CURRENT_BINARY_DIR}/final_linker.ld"
)

# 或者是旧版本的方式
set_target_properties(${PROJECT_NAME} PROPERTIES 
    LINK_FLAGS "-T${CMAKE_CURRENT_BINARY_DIR}/final_linker.ld"
)

6. 方案优势

  1. 高度解耦：硬件参数由 CMake 管理（可以来自 Kconfig 或 YAML），逻辑结构由模板管理。
  2. 避免重复：通用的 SECTIONS 定义只需要写一份，所有板型通过参数注入差异。
  3. 支持复杂逻辑：通过 CPP，可以实现类似 #ifdef ENABLE_TRUSTZONE 这种在链接层面改变内存布局的高级功能。
  4. CI/CD 友好：可以轻松通过命令行参数 -DFLASH_SIZE=2048K 来构建不同规格的固件，而无需修改任何代码。

7. 注意事项

  • 语法冲突：有些链接脚本语法包含 #（如某些注释风格），在经过 CPP 处理时可能会被误认为是预处理指令。建议使用 /* ... */ 风格的注释。
  • 路径问题：使用 CMAKE_CURRENT_BINARY_DIR 存放生成的脚本，避免污染源代码目录，并确保在 Clean 构建时能正确清理。
  • 构建依赖：务必使用 add_dependencies 确保在执行链接之前，脚本已经生成完毕。

总结

通过将 CMake 的模板能力与 C 编译器的预处理能力相结合，我们可以构建出一套极其灵活的链接脚本自动化生成框架。这不仅提升了代码的复用性，也极大降低了在多硬件平台迁移时的出错概率。对于追求工程化水平的嵌入式团队来说，这是迈向 DevOps 的重要一步。

码农架构师 CMake链接脚本嵌入式开发

评论点评