c - 在C中访问链接脚本变量的“值”是否未定义行为？

Question

GNU ld(链接程序脚本)手册3.5.5 Source Code Reference节中有一些非常重要的信息，说明如何在C源代码中访问链接程序脚本“变量”(实际上只是整数地址)。我用了这个信息。广泛使用链接描述文件变量，我在这里写了这个答案:How to get value of variable defined in ld linker script from C。

但是，这样做很容易出错，并且会尝试(错误地)尝试访问链接程序脚本变量的值而不是其地址，从而导致错误，因为这有点深奥。手册(上面的链接)说:

这意味着您无法访问
链接描述文件定义的符号的值-它没有值-您所能做的就是访问链接描述文件定义的符号的地址。

因此，当您在源代码中使用链接器脚本定义的符号时，应始终获取符号的地址，并且切勿尝试使用其值。

问题:因此，如果您确实尝试访问链接程序脚本变量的值，这是“未定义的行为”吗？

快速复习:

想象一下在链接描述文件中(例如: STM32F103RBTx_FLASH.ld )，您具有:

/* Specify the memory areas */
MEMORY
{
    FLASH (rx)      : ORIGIN = 0x8000000,  LENGTH = 128K
    RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 20K
}

/* Some custom variables (addresses) I intend to access from my C source code */
__flash_start__ = ORIGIN(FLASH);
__flash_end__ = ORIGIN(FLASH) + LENGTH(FLASH);
__ram_start__ = ORIGIN(RAM);
__ram_end__ = ORIGIIN(RAM) + LENGTH(RAM);

在C源代码中，您可以执行以下操作:

// 1. correct way A:
extern uint32_t __flash_start__;
printf("__flash_start__ addr = 0x%lX\n", (uint32_t)&__flash_start__);

// OR 2. correct way B (my preferred approach):
extern uint32_t __flash_start__[]; // not a true array; [] is required to access linker script variables (addresses) as though they were normal variables
printf("__flash_start__ addr = 0x%lX\n", (uint32_t)__flash_start__);

// OR 3. COMPLETELY WRONG WAY TO DO IT!
// - IS THIS UNDEFINED BEHAVIOR?
extern uint32_t __flash_start__;
printf("__flash_start__ addr = 0x%lX\n", __flash_start__);

样本打印输出

(这是真实的输出:它实际上是由STM32 MCU编译，运行和打印的):

__flash_start__ addr = 0x8000000

__flash_start__ addr = 0x8000000

__flash_start__ addr = 0x20080000 <==注意，就像我之前所说的:这是完全错误的(即使它可以编译并运行)! <==更新2020年3月:实际上，请看我的回答，这也很好，没错，它所做的只是与众不同。

更新:

回应@Eric Postpischil的第一则评论:

C标准根本没有定义关于链接脚本符号的任何内容。任何行为规范都取决于GNU工具。就是说，如果一个链接描述文件符号标识了内存中某个有效对象的存储位置，那么我希望访问该对象的值是可行的，前提是使用正确的类型对其进行了访问。假设 flash_start 通常是可访问的内存，并且除了系统中关于 flash_start 的任何要求外，理论上，您可以放入uint32_t(使用链接器的适当输入)，然后通过 flash_start 访问它。

是的，但这不是我的问题。我不确定您是否正在回答我的问题的精妙之处。看一下我提供的示例。确实可以访问此位置，但是请确保您了解自己的操作方式，然后我的问题就会变得很明显。尤其要看上面的示例3，尽管对于C程序员来说看起来是正确的，但这是错误的。要读取 uint32_t，例如，在 __flash_start__，您可以这样做:

extern uint32_t __flash_start__;
uint32_t u32 = *((uint32_t *)&__flash_start__); // correct, even though it *looks like* you're taking the address (&) of an address (__flash_start__)

或这个:

extern uint32_t __flash_start__[];
uint32_t u32 = *((uint32_t *)__flash_start__); // also correct, and my preferred way of doing it because it looks more correct to the trained "C-programmer" eye

但最绝对不是这样的:

extern uint32_t __flash_start__;
uint32_t u32 = __flash_start__; // incorrect; <==UPDATE: THIS IS ALSO CORRECT! (and more straight-forward too, actually; see comment discussion under this question)

不是这个:

extern uint32_t __flash_start__;
uint32_t u32 = *((uint32_t *)__flash_start__); // incorrect, but *looks* right

有关:

Why do STM32 gcc linker scripts automatically discard all input sections from these standard libraries: libc.a, libm.a, libgcc.a?

https://stackoverflow.com/a/54728097/4561887

Answer 1

简短的答案:

只要您希望将实际数据存储在内存中的该位置而不是该内存的地址或链接描述文件的“值”中，访问链接描述文件变量的“值”不是未定义的行为，并且可以做得到变量，恰好被C代码视为内存中的地址仅和而没有一个值。

是的，这有点令人困惑，因此请仔细阅读三遍。 本质上，如果要访问链接描述文件变量的值，只需确保已设置链接描述文件，以防止不需要的内容以该内存地址结尾，那么实际上您想要的任何内容都在那里。这样，读取该内存地址上的值将为您提供一些有用的信息。

但是，如果您使用链接程序脚本变量本身来存储某种“值”，则在C中获取这些链接程序脚本变量的“值”的方法是读取其地址，因为“您在链接器脚本中分配的变量由C编译器作为该链接器脚本变量的“地址”显示，因为链接器脚本旨在操纵内存和内存地址，而不是传统的C变量。

在我的问题下，这里有一些非常有价值且正确的评论，我认为值得在此答案中发布，因此它们永远不会丢失。请根据我在上述问题上对他的评论进行投票。

C标准根本没有定义关于链接脚本符号的任何内容。任何行为规范都取决于GNU工具。就是说，如果一个链接描述文件符号标识了内存中某个有效对象的存储位置，那么我希望访问该对象的值是可行的，前提是使用正确的类型对其进行了访问。假设__flash_start__通常是可访问的内存，并且除了系统对__flash_start__的要求外，从理论上讲，您可以放入uint32_t(使用链接器的适当输入)，然后通过__flash_start__对其进行访问。
–埃里克·波斯特皮希尔(Eric Postpischil)

该文档编写得不太好，您从字面上看也太含糊。这里真正发生的是，链接器的符号“值”概念和编程语言的标识符的“值”概念是不同的。对于链接器，符号的值只是与之关联的数字。在编程语言中，该值是存储在与标识符关联的(有时是名义上的)存储中的数字(或某种类型的值的集合中的其他元素)。文档建议您链接器的符号值出现在C语言之内，作为与标识符关联的地址，而不是其存储内容...

这部分非常重要，我们应该更新GNU链接器脚本手册:

当它告诉您“从不尝试使用其值”时，它就太过分了。

正确的是，仅定义链接器符号不会为编程语言对象保留必要的存储空间，因此仅具有链接器符号不会为您提供可以访问的存储空间。但是，如果，您用来确保通过分配存储空间，则可以通过其他方式进行分配，那么可以肯定，它可以用作编程语言对象。 如果您已正确分配存储空间并满足其他要求，则在使用C中的链接符作为标识符方面没有普遍禁止，包括访问其C值。 如果__flash_start__的链接器值是一个有效的内存地址，并且您已确保在该地址上存储uint32_t，并且它是uint32_t的正确对齐地址，则可以在C中访问__flash_start__，就像访问它一样是uint32_t。那不是由C标准定义的，而是由GNU工具定义的。
–埃里克·波斯特皮希尔(Eric Postpischil)

长答案:

我在问题中说:

// 1. correct way A:
extern uint32_t __flash_start__;
printf("__flash_start__ addr = 0x%lX\n", (uint32_t)&__flash_start__);

// OR 2. correct way B (my preferred approach):
extern uint32_t __flash_start__[]; // not a true array; [] is required to access linker script variables (addresses) as though they were normal variables
printf("__flash_start__ addr = 0x%lX\n", (uint32_t)__flash_start__);

// OR 3. COMPLETELY WRONG WAY TO DO IT!
// - IS THIS UNDEFINED BEHAVIOR?
extern uint32_t __flash_start__;
printf("__flash_start__ addr = 0x%lX\n", __flash_start__);

(请参阅问题下有关我如何解决此问题的讨论)。

专门查看上方的＃3:

好吧，实际上，如果您的目标是读取 __flash_start__的地址(在这种情况下为 0x8000000)，那么可以，这是完全错误的。但是，这不是未定义的行为!实际上，它实际上是在读取该地址( 0x8000000)的内容(值)作为 uint32_t类型。换句话说，它只是读取FLASH节的前4个字节，并将它们解释为 uint32_t。在这种情况下，内容(此地址的 uint32_t值)恰好是 0x20080000。

为了进一步证明这一点，以下内容完全相同:

// Read the actual *contents* of the __flash_start__ address as a 4-byte value!
// The 2 techniques should be the same.
extern uint32_t __flash_start__;
uint32_t u32_1 = __flash_start__;
uint32_t u32_2 = *((uint32_t *)&__flash_start__);
printf("u32_1 = 0x%lX\n", u32_1);
printf("u32_2 = 0x%lX\n", u32_2);

输出为:

u32_1 = 0x20080000
u32_2 = 0x20080000

注意它们产生相同的结果。它们每个都产生一个有效的 uint32_t类型值，该值存储在地址 0x8000000中。

但是，事实证明，上面显示的 u32_1技术是一种更直接，直接的读取值的方式，而且并非唯一的行为。而是，它正在正确读取该地址的值(内容)。

我好像在圈子里说话。无论如何，我的想法很震撼，但我现在明白了。在我应该只使用上面显示的 u32_2技术之前，我就被说服了，但事实证明，它们都很好，而且 u32_1技术显然更简单(我又在圈子里说话)。 :)

干杯。

深入探讨:在我的FLASH存储器开始处存储的 0x20080000值是从哪里来的？

一个小花絮。我实际上是在具有512KiB RAM的STM32F777 MCU上运行了此测试代码。由于RAM从地址0x20000000开始，这意味着0x20000000 + 512K = 0x20080000。正是由于 Programming Manual PM0253 Rev 4，pg，这恰好也是地址为零的RAM的内容。图42中的“图10.向量表”显示向量表的前4个字节包含“初始SP [堆栈指针]值”。看这里:



我知道向量表位于程序存储器的开始位置，该程序位于Flash中，因此这意味着0x20080000是我的初始堆栈指针值。这是有道理的，因为 Reset_Handler是程序的开始(顺便说一下，它的向量恰好是向量表开始处的第二个4字节值)，并且它首先要做的是，如图所示在我的“ startup_stm32f777xx.s ”启动程序集文件中，将堆栈指针(sp)设置为 _estack:

Reset_Handler:  
  ldr   sp, =_estack      /* set stack pointer */

此外， _estack在我的链接描述文件中定义如下:

/* Highest address of the user mode stack */
_estack = ORIGIN(RAM) + LENGTH(RAM);    /* end of RAM */

所以你有它!我的向量表中位于Flash开头的第一个4字节值设置为初始堆栈指针值，该值在我的链接程序脚本文件中定义为 _estack，而 _estack是我的末尾地址RAM，即0x20000000 + 512K = 0x20080000。所以，这一切都说得通!我刚刚证明我读了正确的值!