嵌入式C++项目必须手写链接器脚本，因裸机/RTOS无OS管理内存布局，需精确控制.text/.data/.bss等段的物理地址；须用MEMORY定义Flash/RAM区域，SECTIONS中显式处理.init_array以保障全局对象构造，并导出_sdata/_sidata/_edata供startup复制.data。
为什么嵌入式 C++ 项目必须手写链接器脚本？
因为裸机或 RTOS 环境下没有操作系统接管内存布局，.text、.data、.bss 这些段默认会按工具链默认规则排布——很可能把代码塞进 RAM、把未初始化变量放在 Flash 地址上，直接导致启动失败或运行时崩溃。链接器脚本（通常叫 linker.ld）是唯一能精确控制每个段落物理地址和大小的手段。
如何定义 MEMORY 区域并映射到真实硬件？
必须先用 MEMORY 告诉链接器芯片的真实资源：哪些地址是 Flash、哪些是 RAM、起始和长度多少。漏写、写反顺序、地址重叠都会让 ld 报错或静默错配。
-
FLASH区域必须从芯片手册确认的 Boot 地址开始（比如0x08000000），长度不能超过实际 Flash 容量 -
RAM区域要避开栈/堆预留区（例如 STM32 的0x20000000开始，但前 4KB 可能被_estack占用） - 多个 RAM 区（如 DTCM/SRAM1/SRAM2）需分别命名，后续用
REGION显式指定段归属
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
如何把 C++ 全局对象构造函数塞进 .init_array？
普通 C 项目不关心这个，但 C++ 的全局对象（含 static 局部对象）构造函数必须在 main() 前执行。GCC 用 .init_array 段收集这些函数指针，而默认链接脚本常忽略它——结果就是对象没构造、std::cout 或自定义单例直接崩。
- 必须显式声明
.init_array段，并确保它位于 RAM 中（因为函数指针要运行时读取） - 加上
PROVIDE定义__init_array_start和__init_array_end符号，C runtime 才能遍历调用 - 别忘了
.fini_array（析构函数），虽然嵌入式很少用，但留着更健壮
SECTIONS
{
.text : { *(.text) }
.rodata : { *(.rodata) }
.init_array : {
PROVIDE(__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array))
PROVIDE(__init_array_end = .);
} > RAM
.data : { *(.data) } > RAM AT > FLASH
.bss : { *(.bss) } > RAM
}
为什么 .data 复制代码必须由 startup 文件触发？
链接脚本只定义布局，不生成复制逻辑。.data 在 Flash 里存初值，上电后得靠 startup 汇编/C 代码把它拷到 RAM 对应位置——否则 int x = 42; 的 x 在 RAM 里还是随机值。
立即学习“C++免费学习笔记（深入）”；
- 链接脚本中
.data > RAM AT > FLASH是关键：前者指定运行时地址（RAM），后者指定加载时地址（Flash） - 必须导出
_sidata（Flash 中 .data 起始）、_sdata（RAM 中 .data 起始）、_edata（RAM 中 .data 结束）三个符号供 startup 使用 - C++ 的
constexpr全局变量若被放入.rodata，则无需复制；但带非 trivial 构造的静态对象仍依赖.init_array流程
SECTIONS
{
.data : {
_sdata = .;
*(.data)
_edata = .;
} > RAM AT > FLASH
_sidata = LOADADDR(.data);
}
链接器脚本不是“写完就能跑”的配置文件，它和 startup 代码、编译选项（比如 -fno-exceptions 是否影响 .init_array 内容）、甚至 C++ 标准库实现强耦合。一个字符写错（比如把 > 写成 >>）就可能让整个 .data 段被丢进未映射地址。调试时优先检查 map 文件里各段的 LMA 和 VMA 是否符合预期。 
