C 在调用堆栈中，当指针类型的参数保持模式0x80808080或0xF8F8F8的地址时，它指示什么？

当我使用GDB调试一个问题时，我遇到了这种奇怪的行为。对此，我无法用任何合乎逻辑的答案说服自己

下面是由于函数开头的断点而获得的调用堆栈快照（为了简单起见，我将堆栈帧限制为3级）

我尝试了更多的东西，希望它能帮助理解这种行为

我将一个有效地址

0x7fffd7e4f5b8

-分配给

哈希集

(gdb) s hashset=0x7fffd7e4f5b8
(gdb) p *hashset
Cannot access memory at address 0xb8b8b8b8b8b8b8b8
(gdb) p hashset
$6 = (hashset) 0xb8b8b8b8b8b8b8b8

但令我惊讶的是，当我打印
哈希集的值时，它将地址显示为
0xb8b8b8
，而不是
0x7fffd7e4f5b8

有人能解释一下这里发生了什么事吗

[编辑：没有崩溃/挂起。系统正常运行]

我知道，当GDB将任何变量显示为“value optimized out”时，它表示它的值存储在寄存器中，而不是存储在堆栈帧上

这不是“价值优化”的意思

这意味着：编译器没有在当前程序计数器处提供此变量的位置信息

理论上，
DWARF
标准非常丰富，它可以描述“通过将
常量
添加到
寄存器
的值中来定位此变量”，或者“通过添加
寄存器A
和
寄存器B
并使用寄存器C所指向的
位置内容对结果进行ORing”。实际上，很少有编译器达到这样的长度，而只是简单地省略信息

然而，在本例中，最初显示为“值优化输出”的arg hashset后来被更改为某个地址位置

当您提升程序计数器时，GDB在新电脑上找到了位置信息。但解释该位置信息会产生值
0xf8f8
，该值不能是
x86\u 64
上指针的真实值

由此可以得出结论，要么位置信息不正确（很可能是编译器错误），要么GDB没有正确解释
DWARF
描述（并非闻所未闻）

不幸的是，在调试优化的代码时，这样的调试工件是不争的事实。它们还依赖于GCC和GDB的确切版本——较新的版本通常（但并不总是！）更好。Clang/LLVM目前相当差，产生“值优化输出”的频率比它应该的要高。
听起来像是你在内存总线上挂了一些设备。您正在调试什么平台操作系统和硬件？系统未挂起。它正常运行。每次我围绕该API进行步骤调试时，我都会看到这种行为。当我在x86_64上运行Linux内核时，该值看起来像是一个未初始化的指针，编译器/运行时为其设置了此值，因此在未正确分配指针的情况下使用指针时会产生问题（seg错误）。@DarshanL它只显示gdb能够访问程序内存。也许你可以试着用
-O0-g
编译你的程序。可能是代码优化了，gdb无法在程序中显示
hashset
的值。此时，请发布一个
    (gdb) bt
#0  hashset_get (hashset=0xf8f8f8f8f8f8f8f8, item_key=0x7fffd7e4f5b8)
    at /xxx/yyy/zzz/hashset.c:125
#1  0x00007fffed855d00 in hashmap_get (hashmap=<value optimized out>, key=0x7fffd7e4f648)
    at /xxx/yyy/zzz/hashmap.c:789
#2  0x00007ffa589d8eeb in hashmap_get_value (hashmap=0x7ff9d82d1b78, key=0x7fffd7e4f648)
    at /xxx/yyy/zzz/hashmap.c:456

(gdb) p *hashset
Cannot access memory at address 0xf8f8f8f8f8f8f8f8

(gdb) s hashset=0x7fffd7e4f5b8
(gdb) p *hashset
Cannot access memory at address 0xb8b8b8b8b8b8b8b8
(gdb) p hashset
$6 = (hashset) 0xb8b8b8b8b8b8b8b8