如何声明一个占用内存部分中所有可用空间的 C 数组？

Question

假设我有一个 128KB 的内存区域。在我的链接器指令中，我将此区域分为三个部分：

• .section_text
• .section_data
• .section_bss

每个部分的大小在预编译时未知，但我已限制 .section_bss 使用 .section_text 和 .section_data 之后内存区域内的所有剩余空间被分配。

有什么方法可以声明一个用尽 .region_bss 中所有可用空间的 C 数组吗？假设它是唯一使用 .region_bss 的东西，这样它就可以安全地使用整个区域。出于示例目的，但显然是错误的：

char entire_bss[sizeof(.region_bss)];

以下是我对一些预期答复的预先答复。首先，我知道 sizeof() 不是这样工作的。我只是用它来传达一个想法。其次，假设这必须使用数组而不是指针来完成（使用指针求解是可能的并且相当简单）。第三，我知道我可以获得 .region_bss 的起始地址和结束地址，但我不知道有什么方法可以使用它们来调整数组的大小。至少没有任何方法可以在 C 中工作。

很可能没有办法做到这一点，但我希望那里的一些天才已经弄清楚了。如果您可以使其与 Green Hills 工具集一起使用，则额外加分。

Answer 1

有什么方法可以声明一个 C 数组，它会耗尽 .region_bss 中的所有可用空间？

简短的回答是“不”。

如果 GreenHills 使用 GNU 工具链和 binutils 并允许自定义 链接器脚本，然后您可以向应用程序命名空间添加一个变量 使用 PROVIDE 来标记128K 块的末尾。 （参见如何访问此类变量的示例 这里）。这样你就不会得到固定大小的 C 数组，但程序将能够找到数组的末尾，因此数组的大小通常足以满足 C 程序的需要。

如果您想使用纯 C99 来实现这一点，那么您可能会运气不好，因为它是 高度不可靠，因为它不在标准范围内。

Answer 2

通常，您执行此操作的方式如下：

extern char section_bss[];

添加一些额外的内容，以便编译器、汇编器和链接器知道 section_bss 是 .section_bss 的别名（或类似的名称）。

要获得大小，您可能需要对 bss 末尾的符号执行相同的操作并找出差异。

Answer 3

不，你不能。原因也很容易理解。在编译阶段，没有 .bss 和 .data 的概念，这些是纯粹的链接器约定。编译器知道一些抽象概念（常量数据、静态数据、代码），但它们到链接器部分的映射只是一种约定，并且取决于链接器、操作系统和处理器甚至内存模型选项。例如，在构建位置无关代码时，通常将常量放入代码段中。在嵌入式平台上，有时您必须与这些事情作斗争，甚至因此必须调整您的编码风格（我们曾经有一个基于 80186 处理器的模型，该处理器是用 MS-C 5.1 编译器构建的，如果我们不能使用 < code>.data 部分（全局、初始化变量和静态），因为工具链将它们放入 ROM 中，

我们通过在整个构建过程结束时修补生成的二进制文件解决了您的类似问题。链接器生成的映射文件中不同部分的已用内存（这是一个选项，可以查找），并从给定模型的内存大小中减去它（我们有 256K、512K 和 896K 模型），然后设置其中之一因此，对这个大小的所有引用都必须通过这个全局变量来工作，这一点很重要，然后我们的 malloc/free 实现就会使用这个内存池。 。

Answer 4

您想要做的事情将非常依赖于平台。您最好的选择可能是将数组声明为 extern char the_array[],end_of_array[];在您的 C 文件中，然后可能在汇编语言源文件中，为 the_array 和 end_of_array 声明几个数据部分。然后安排链接器规范，以便 the_array 将位于自下而上分配的内容的末尾，而 end_of_array 将位于自上而下分配的内容的开头，并且它们之间不会有任何其他内容。这是可能的——我已经在某些平台上做到了——但仔细阅读链接器文档很重要，以确保链接器不会在您不期望的时候重新安排事情。

Answer 5

有什么问题吗

extern char __ghsbegin_region_bss[];
extern char __ghssize_region_bss[];
#define entire_bss __ghsbegin_region_bss
#define sizeof_entire_bss ((size_t)__ghssize_region_bss)

？我可以想到至少一个你可能对这个答案不满意的原因，但它涉及 C++ 模板元编程魔法（即，entire_bss 的类型不会具有正确的大小，因此取决于其大小的模板会以不同的方式解析）。只要您不将数组的大小用于任何用途（在 C 中也是如此），这种方法应该没问题。

请注意，__ghssize_region_bss 不是编译时常量 - 它直到链接时才解析 - 因此 100% 无法将其放入 [...] 中编译时的数组类型。

请参阅 Green Hills 手册中有关“部分符号的开始、结束和大小”的章节。