基于GNU交叉工具链，如何创建固定内存地址的静态驻留共享库

针对你需要构建固定在已知内存地址、供多固件可执行文件调用的共享组件需求，基于GNU交叉工具链，以下是标准可靠的实现步骤：

1. 编写专用链接脚本 #

核心是通过链接脚本指定库的固定内存地址、段布局，并保护导出符号不被丢弃。示例脚本library.ld：

MEMORY
{
  LIB_REGION (rx) : ORIGIN = 0x80010000, LENGTH = 0x2000 /* 替换为实际起始地址和可用空间大小 */
}

SECTIONS
{
  .text :
  {
    KEEP(*(.text*)) /* 强制保留所有代码段，防止优化丢弃 */
  } > LIB_REGION

  .rodata :
  {
    *(.rodata*)
  } > LIB_REGION

  .data :
  {
    *(.data*)
  } > LIB_REGION

  .bss :
  {
    *(.bss*)
  } > LIB_REGION

  /* 标记库的起止地址，可选但便于后续内存管理 */
  PROVIDE_HIDDEN(__lib_start = .);
  PROVIDE_HIDDEN(__lib_end = .);
}

• MEMORY块：定义库的内存区域，ORIGIN是你预设的固定起始地址，LENGTH是库的最大占用空间。
• KEEP()指令：确保链接器不会丢弃未被当前库引用的导出函数（比如只被外部固件调用的函数）。

2. 编译库源文件为目标文件 #

用交叉工具链编译库的源码，添加必要选项避免不必要的优化：

# 替换为你的交叉工具链前缀，比如arm-none-eabi-、mipsel-linux-gnu-等
<cross-prefix>-gcc -c -o lib_components.o lib_components.c -O2 -ffunction-sections -fdata-sections

• -ffunction-sections/-fdata-sections：将每个函数/数据项放在独立段中，配合链接脚本的KEEP()更精准控制符号保留。
• 若需确保特定函数不被编译器优化，在源码中给函数添加__attribute__((used))修饰：

  __attribute__((used)) void shared_uart_send(const char* data) {
    // 函数实现
  }
  

3. 链接生成固定地址的库ELF文件 #

使用链接脚本将目标文件链接为地址固定的ELF（无需dummy main函数）：

<cross-prefix>-ld -T library.ld -o library.elf lib_components.o

生成的library.elf中，所有符号的地址都已固定到你指定的内存区域。

4. 提取符号表供固件可执行文件使用 #

从库ELF中提取全局符号的地址信息，生成library.syms文件供后续固件链接使用：

<cross-prefix>-nm -g -P library.elf | grep -v '^$' | awk '{print $1 " " $2}' > library.syms

• -g：仅提取全局符号（外部可调用的函数/变量）。
• -P：采用POSIX标准格式输出，便于后续处理。
• 最终生成的library.syms包含符号名和对应固定地址，可直接用于ld --just-symbols=library.syms链接固件可执行文件。

5. 验证正确性 #

通过objdump确认库的符号地址是否符合预期：

<cross-prefix>-objdump -t library.elf | grep shared_uart_send

输出的地址应与你在链接脚本中设定的ORIGIN匹配。

对比"dummy main"方案的优势 #

此方案无需创建虚假的main函数，完全通过链接脚本和编译选项控制地址与符号保留，从工具链层面保证可靠性：

• 避免因dummy main引入的冗余代码或潜在优化问题。
• 精准控制符号保留，不会出现导出函数被意外丢弃的情况。

内容的提问来源于stack exchange，提问作者Eugene Sh.