【发布时间】：2019-09-01 11:31:35
【问题描述】：
GNU ld（链接器脚本）手册部分3.5.5 Source Code Reference 提供了一些关于如何在C 源代码中访问链接器脚本“变量”（实际上只是整数地址）的重要信息。我用了这个信息。广泛使用链接器脚本变量，我在这里写了这个答案：How to get value of variable defined in ld linker script from C。
但是，很容易做错并尝试访问链接描述文件变量的值（错误地）而不是其地址，因为这有点深奥。手册（上面的链接）说：
这意味着您无法访问 链接描述文件定义符号的值 - 它没有价值 - 你所能做的就是访问链接描述文件定义符号的地址。
因此，当您在源代码中使用链接描述文件定义的符号时，您应该始终获取符号的地址，并且永远不要尝试使用它的值。
问题：那么，如果您确实尝试访问链接描述文件变量的值，这是“未定义行为”吗？ p>
快速复习：
想象一下在链接器脚本中（例如：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__ = ORIGIN(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 单片机编译、运行和打印的）：
__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
相关：
【问题讨论】：
-
C 标准根本没有定义任何关于链接描述文件符号的内容。任何行为规范都取决于 GNU 工具。也就是说，如果链接描述文件符号标识了内存中存储某些有效对象的位置，那么我希望访问该对象的值能够正常工作，如果它是以其正确的类型访问的。假设
__flash_start__通常是可访问的内存，并且除了您的系统对__flash_start__的内容有任何要求外，理论上您可以放置一个uint32_t（使用链接器的适当输入）然后通过@ 访问它987654339@. -
我不确定你是否注意到我的问题的微妙之处，我需要更多的空间来回复，所以我直接在上面问题的底部回复了你的评论。
-
那个文档写得不是很好，而且你把第一句话看得太字面意思了。这里真正发生的是，链接器对符号“值”的概念和编程语言对标识符“值”的概念是不同的。对于链接器来说，符号的值只是一个与之关联的数字。在编程语言中，值是存储在与标识符关联的（有时是名义上的）存储中的数字（或某种类型的值集中的其他元素）。...
-
... 文档建议您链接器的符号值出现在像 C 这样的语言中，作为与标识符关联的地址，而不是其存储的内容。当它告诉你“永远不要尝试使用它的价值”时，它就太过分了。正确的是，仅定义链接器符号不会为编程语言对象保留必要的存储空间，因此仅具有链接器符号并不能为您提供可以访问的存储空间。但是，如果您确保通过其他方式分配存储空间，那么，当然……
-
……它可以作为编程语言对象工作。 没有一般禁止在 C 中使用链接器符号作为标识符，包括访问其 C 值，前提是您已正确分配存储空间或满足此要求。 如果链接器值为 @987654340 @ 是一个有效的内存地址，并且您已确保在该地址有
uint32_t的存储空间，并且它是uint32_t的正确对齐地址，然后可以在 C 中访问__flash_start__就好像它一样是uint32_t。这不是由 C 标准定义的，而是由 GNU 工具定义的。
标签： c linker ld binutils linker-scripts