相关：

Question

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

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

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

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

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

快速复习：

想象一下在链接描述文件中（例如： 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 <==就像我上面提到的那样：这是完全错误的（即使它可以编译并运行）！

更新：

回复@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

相关：

Answer 1

我在问题中说：

// 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）的 contents （值）。换句话说，它只是读取FLASH节的前4个字节，并将它们解释为uint32_t。在这种情况下， contents （此地址处的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技术是一种更直接，直接的读取值的方法，而且 not 是未定义的行为。相反，它正在正确读取该地址的值（内容）。

我似乎在圈子里说话。无论如何，让我感到震惊，但我现在明白了。在我应该只使用上面显示的u32_2技术之前，我就被说服了，但是事实证明它们都很好，而且，u32_1技术显然更加简单明了（我去了再说一遍）。：）

干杯。

深入研究：正好在我的FLASH存储器开始处存储的`0x20080000`值是从哪里来的？

一个小花絮。我实际上是在具有512KiB RAM的STM32F777 MCU上运行了此测试代码。由于RAM从地址0x20000000开始，这意味着0x20000000 + 512K = 0x20080000。恰好也是地址0处RAM的内容，因为Programming Manual PM0253 Rev 4，pg。图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。所以，这一切都说得通！我刚刚证明我读了正确的值！

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

快速复习：

样本打印输出

更新：

相关：

1 个答案:

深入研究：正好在我的FLASH存储器开始处存储的`0x20080000`值是从哪里来的？

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

快速复习：

样本打印输出

更新：

相关：

1 个答案:

深入研究：正好在我的FLASH存储器开始处存储的0x20080000值是从哪里来的？

深入研究：正好在我的FLASH存储器开始处存储的`0x20080000`值是从哪里来的？