LLD中ENTRY仅接受真实定义的符号，不支持GNU ld的回退逻辑；若符号未定义则直接报错，且解析严格区分大小写、不支持隐式容错。
ENTRY在LLD中如何被解析和生效
LLD 支持 ENTRY，但行为比 GNU ld 更严格：它只接受一个符号名，且该符号必须在最终链接输入中**真实定义**（不能仅由 PROVIDE 或 ASSIGN 声明）。如果符号未定义，LLD 直接报错 undefined symbol: _start，不会退回到默认逻辑（如 GNU ld 会 fallback 到 .text 起始地址）。
常见错误现象：
- 用
ENTRY(_start)但汇编启动文件里写的是start:（少下划线）或Reset_Handler（名不匹配） - 在 C 启动代码中用
void _start(void)，但没加__attribute__((naked, section(".text.start")))，导致被编译器优化或重命名 -
ENTRY出现在脚本中间而非顶部，LLD 虽不报错，但部分旧版本（
实操建议：
- 始终把
ENTRY放在链接脚本最开头，紧随注释之后 - 用
nm -C your.elf | grep _start确认符号确实存在且类型为T（text） - 避免依赖
PROVIDE(_start = .)来“兜底”，LLD 不保证该PROVIDE能参与入口解析
KEEP在LLD中是否保留未引用的段
KEEP 在 LLD 中**完全支持**，语义与 GNU ld 一致：强制将括号内指定的输入段（或整个输入文件）保留在输出中，即使它们未被任何符号引用。这是实现中断向量表、初始化函数数组（如 __init_array_start）、自定义段（如 .vector_table）的关键机制。
容易踩的坑：
-
KEEP(*(vector_table))写成KEEP(*vector_table)—— 缺少括号，LLD 报错syntax error - 对已声明为
NOLOAD的段（如.bss）误用KEEP，实际无效（KEEP控制“是否丢弃”，NOLOAD控制“是否加载”，二者正交） - 在
SECTIONS外使用KEEP（如直接写在脚本顶层），LLD 忽略且不警告
典型写法示例：
.vector_table : {
KEEP(*(.vector_table))
} > FLASH
注意：KEEP 只影响段内容是否被链接器丢弃，不影响其地址分配 —— 地址仍由 SECTIONS 块内的位置计数器 . 或显式地址控制。
LLD处理链接脚本时的两个关键差异点
LLD 对链接脚本的解析更“字面化”，不带 GNU ld 那种隐式容错逻辑。这意味着：
-
MEMORY中的区域名若在SECTIONS里拼错（如写成>FLASH但MEMORY定义的是flash (rx)），LLD 报错region 'FLASH' not declared，而 GNU ld 可能静默 fallback 到默认区域 -
AT>region和>region必须指向同一MEMORY块中已声明的名称，大小写敏感，且不能是别名或宏展开结果 -
PROVIDE定义的符号若用于ENTRY或段地址计算（如. = PROVIDE(__stack_top = ORIGIN(RAM) + LENGTH(RAM));），必须确保该PROVIDE出现在所有依赖它的语句之前 —— LLD 不做全局前向解析
真正容易被忽略的是：LLD 默认不生成 .map 文件，而 KEEP 是否生效、ENTRY 是否被采纳，最可靠的验证方式不是看链接是否成功，而是用 llvm-readobj --sections your.elf 检查目标段是否存在，以及 llvm-readelf -h your.elf | grep Entry 确认入口值。
