为什么STM32 gcc链接程序脚本会自动丢弃以下标准库中的所有输入节:libc.a,libm.a,libgcc.a? [英] Why do STM32 gcc linker scripts automatically discard all input sections from these standard libraries: libc.a, libm.a, libgcc.a?

查看:361
本文介绍了为什么STM32 gcc链接程序脚本会自动丢弃以下标准库中的所有输入节:libc.a,libm.a,libgcc.a?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

从任何自动生成的STM32CubeMx生成的链接器脚本的底部:

From the bottom of any auto-generated STM32CubeMx-generated linker script:

/* Remove information from the standard libraries */
/DISCARD/ :
{
  libc.a ( * )
  libm.a ( * )
  libgcc.a ( * )
}

从GNU Binutils ld(链接程序脚本)手册中, 3.6.7丢弃输出节:

From the GNU Binutils ld (linker script) manual, 3.6.7 Output Section Discarding:

特殊的输出节名称"/DISCARD/"可用于丢弃输入节.分配给名为"/DISCARD/"的输出节的任何输入节均不包含在输出文件中.

The special output section name ‘/DISCARD/’ may be used to discard input sections. Any input sections which are assigned to an output section named ‘/DISCARD/’ are not included in the output file.

这3个输入对象文件包含什么,为什么我们丢弃它们中的所有内容(所有输入部分)?

What do these 3 input object files contain, and why do we discard everything (all input sections) from them?

  1. 正在访问值"C中链接脚本变量未定义行为的说明?
  2. 如何从C获取ld链接程序脚本中定义的变量的值

推荐答案

类似于本示例,/DISCARD/会删除脚本未明确定义的任何其他节.例如,由于 *(.text) *(.data) *(.bss) *(.init_array)等,已在脚本的前面定义,它们进入了ELF.但是 libc libm libgcc 可能包含不必要的固件部分(例如.foo,.bar,.debug ...),因此/DISCARD/只是抹掉它们,但不是所有部分!

Looks like in this example, /DISCARD/ removes any other sections, that are not explicitly defined by script. For example, since *(.text), *(.data), *(.bss), *(.init_array) etc, has been defined earlier in the script, they get into the ELF. But libc, libm or libgcc could contain unnecessary sections for firmware (e.g. .foo, .bar, .debug ...), so /DISCARD/ just wipes them out, but NOT all sections!

这篇关于为什么STM32 gcc链接程序脚本会自动丢弃以下标准库中的所有输入节:libc.a,libm.a,libgcc.a?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆