GCC (NOLOAD)-directive 导致错误的内存映射答案

【问题标题】：GCC (NOLOAD)-directive cause wrong memory mappingGCC (NOLOAD)-directive 导致错误的内存映射
【发布时间】：2018-07-23 15:58:21
【问题描述】：

我正在使用 GCC(MIPS)。以下是我的 .ld 文件中的相关部分。

MEMORY
{
   MEMORY_1                : ORIGIN = 0xB014D000,          N
   ....
   MEMORY_N                : ORIGIN = 0x9C00C800,          LENGTH = X*K
}
SECTIONS
{
   ....
 .my_section  ALIGN(32)           (NOLOAD)  : { } > MEMORY_1
   ....
}

代码中全局缓冲区的定义：

static U32 __attribute__((section(".my_section"))) gBuffer[size];

我预计gBuffer[]address 是MEMORY_1，但是，它的地址是0x9c0*****，即MEMORY_N。为什么？我该如何解决？

编辑： 我发现删除NOLOAD 指令后，缓冲区位于MEMORY_1。

(NOLOAD) 指令将标记一个在运行时不加载的部分。链接器将正常处理该部分，但会对其进行标记，以便程序加载器不会将其加载到内存中。

我需要在这里使用 (NOLOAD) 指令。所描述行为的解释是什么？如何在不将缓冲区移动到意外内存的情况下使用 NOLOAD？

EDIT2： ld 文件将如下所示（根据 Matthias 的建议）：

_gBuffer_1 = address(MEMORY_1),
_gBuffer_2 = address(MEMORY_1) + _gBuffer_1_size,
_gbuffer_3 = address(MEMORY_1) + _gBuffer_1_size + _gBuffer_2_size.......

_gBuffer_i_size 必须在 ld 文件中定义。我的代码和很多部分中有很多这样的缓冲区。现在，每次有人希望添加新缓冲区或更改现有缓冲区（删除它或更改其大小......）时，他必须通过 ld 文件并重新计算地址，这就是为什么我发现建议的方法不太容易维护. 最初的方法允许定义缓冲区，在程序员希望的每个部分中轻松找到它，并将其余工作留给链接器。添加(NOLOAD) 指令后引发的问题。

【问题讨论】：

反转地址？
您是否在部分声明周围添加了SECTION{ ... }？
@Matthias，是的，我做到了。
有时，链接器对语法有点过于敏感。你试过>MEMORY_1（即没有空格）吗？
@Matthias。试过了，没用……

标签： c gcc memory attributes ld

【解决方案1】：

我们刚刚遇到了同样的问题。我们的解决方法是添加一个额外的间接层：

.my_section_noload ALIGN(32) (NOLOAD) :
{
  *(.my_section)
} > MEMORY_1

不知道为什么直接使用它不起作用。

【讨论】：

.my_section 是一个输入部分，在这种情况下取自多个 .o 文件（即“*”位）。另一方面，“.my_section_noload”是一个输出节，由链接器在整理输入数据时生成。输出具有相似的名称以避免混淆。从理论上讲，您可以将其称为“.happiness”，但调试器可能需要弄清楚您的意思....
...“类似地”并不是指“完全地”。如果您在 gcc 中使用 -ffunction-sections 生成函数部分，您将有很多 .text 部分（.text.main、.text.function1、.text.init 等）。这些将被指定为*(.text*) 的输入和输出为.text。如果要求链接器进行垃圾收集，它将丢弃未引用的输入部分。

【解决方案2】：

你完全可以避免使用 gcc 属性。只需在链接器文件中提供符号：

_gBuffer = 0xB014D000;

然后你可以将缓冲区声明为extern：

extern U32 gBuffer[size];

现在，链接器应该将 extern 声明绑定到给定地址。

【讨论】：

感谢您的回答。是否有另一种更易于维护的方式来实现相同的目标？我有很多缓冲区和很多部分。谢谢。
我不明白。为什么这种方法比原来的方法更难维护？
@Matthis，您可以在 EDIT2 的原始帖子中找到我的答案，谢谢。