x86 上未对齐的指针

有人可以提供一个示例，将指针从一种类型转换为另一种类型由于未对齐而失败吗？

在评论中这个答案 https://stackoverflow.com/questions/544928/reading-integer-size-bytes-from-a-char-array/544964#544964，博蒂说做类似的事情

char * foo = ...;
int bar = *(int *)foo;

如果启用对齐检查，即使在 x86 上也可能会导致错误。

我试图通过设置对齐检查标志后产生错误条件set $ps |= (1<<18)在GDB中，但什么也没发生。

工作（即非工作；））示例是什么样的？

答案中的代码片段在我的系统上都不会失败 - 我稍后将使用不同的编译器版本并在不同的电脑上尝试它。

顺便说一句，我自己的测试代码看起来像这样（现在也使用 asm 来设置AC标志和未对齐的读写）：

#include <assert.h>

int main(void)
{
    #ifndef NOASM
    __asm__(
        "pushf\n"
        "orl $(1<<18),(%esp)\n"
        "popf\n"
    );
    #endif

    volatile unsigned char foo[] = { 1, 2, 3, 4, 5, 6 };
    volatile unsigned int bar = 0;

    bar = *(int *)(foo + 1);
    assert(bar == 0x05040302);

    bar = *(int *)(foo + 2);
    assert(bar == 0x06050403);

    *(int *)(foo + 1) = 0xf1f2f3f4;
    assert(foo[1] == 0xf4 && foo[2] == 0xf3 && foo[3] == 0xf2 &&
        foo[4] == 0xf1);

    return 0;
}

即使生成的代码肯定包含未对齐的访问，断言也可以顺利通过mov -0x17(%ebp), %edx and movl $0xf1f2f3f4,-0x17(%ebp).

设置也会如此AC触发一个SIGBUS或不？我无法让它在 Windows XP 下的 Intel 双核笔记本电脑上运行，并且没有我测试过的 GCC 版本（MinGW-3.4.5、MinGW-4.3.0、Cygwin-3.4.4），而 codelogic 和 Jonathan Leffler提到 x86 上的失败...

在 x86 上，未对齐的访问会导致问题（除了内存访问需要更长的时间之外），这种情况并不常见。以下是我听说过的一些：

1. 您可能不会将此视为 x86 问题，但 SSE 操作会受益于对齐。对齐的数据可以用作存储源操作数来保存指令。未对齐加载指令，例如movups慢于movaps在 Nehalem 之前的微体系结构上，但在 Nehalem 及更高版本（以及 AMD Bulldozer 系列）上，未对齐的 16 字节加载/存储与未对齐的 8 字节加载/存储的效率大致相同；如果数据恰好在运行时对齐或没有跨越缓存行边界，则不会有任何惩罚，否则对缓存行分割的硬件支持会很高效。在 Skylake 之前，4k 分割非常昂贵（约 100 个周期）（像缓存行分割一样降至约 10 个周期）。看https://agner.org/optimize/ https://agner.org/optimize/和性能链接x86 标签维基 https://stackoverflow.com/tags/x86/info了解更多信息。

2. 互锁操作（例如lock add [mem], eax) are very如果它们没有充分对齐，则速度会很慢，特别是当它们跨越缓存行边界时，因此它们不能只在 CPU 核心内使用缓存锁。在较旧的（有缺陷的）SMP 系统上，它们might实际上无法成为原子的（参见https://blogs.msdn.com/oldnewthing/archive/2004/08/30/222631.aspx https://blogs.msdn.com/oldnewthing/archive/2004/08/30/222631.aspx).

3. Raymond Chen 讨论的另一种可能性是在处理具有硬件存储内存的设备时（诚然是一种奇怪的情况） -https://blogs.msdn.com/oldnewthing/archive/2004/08/27/221486.aspx https://blogs.msdn.com/oldnewthing/archive/2004/08/27/221486.aspx

4. 我记得（但没有参考资料 - 所以我不确定这一点）跨越页面边界的未对齐访问也存在类似问题，也涉及页面错误。我看看是否可以找到这方面的参考。

在研究这个问题时我学到了一些新东西（我想知道“$ps |= (1<<18)“在几个地方提到了 GDB 命令）。我没有意识到 x86 CPU（似乎从 486 开始）有能力在执行未对齐的访问时引发异常。

来自 Jeffery Richter 的“Windows 编程应用程序，第四版”：

让我们仔细看看 x86 CPU 是如何处理数据对齐的。 x86 CPU 在其 EFLAGS 寄存器中包含一个特殊位标志，称为 AC（对齐检查）标志。默认情况下，当 CPU 首次通电时，该标志设置为零。当该标志为零时，CPU 会自动执行其必须执行的操作，以便成功访问未对齐的数据值。然而，如果该标志设置为 1，则每当尝试访问未对齐的数据时，CPU 都会发出 INT 17H 中断。 Windows 2000 和 Windows 98 的 x86 版本永远不会更改此 CPU 标志位。因此，当应用程序在 x86 处理器上运行时，您永远不会看到应用程序中发生数据错位异常。

这对我来说是新闻。

当然，访问未对齐的一个大问题是，当您最终去编译非 x86/x64 处理器的代码时，您最终必须跟踪并修复一大堆东西，因为几乎所有其他 32 位或更大的处理器处理器对对齐问题很敏感。