【发布时间】：2016-02-14 01:58:59
【问题描述】：
我正在使用 netif 结构（类似于 http://www.nongnu.org/lwip/structnetif.html），我遇到了一个与对齐有关的问题。我注意到每个 int 都从一个 4 倍数的地址开始（例如 0x20010db0）。但是，让我们看一下以下内容：
struct netif {
...
u8_t hwaddr_len (at address 0x20010db8)
u8_t[8] hwaddr (at address 0x20010db9)
u8_t mtu (at address 0x20010dc1)
...
}
据我了解，hwaddr_len 在 4 个字节上对齐，hwaddr 在 1 个字节上“对齐”（因为它是 u8_t，这不是在 4 个字节（32 位）上对齐），mtu 在 1 上是“对齐”字节。之后，该结构的所有其他成员再次对齐 4 个字节。所以，我认为这应该很好，即使 hwaddr 在 4 字节多路器上没有对齐，但是当我尝试从“src”到 hwaddr 进行 memcpy 时，我得到了一个未对齐的访问错误。
我正在使用 arm gcc 编译器进行编译。有人知道它为什么会失败吗？
Ps : 我对 ARM 对齐问题了解不多，如果我的问题看起来很明显，请见谅。
编辑：
编译器版本：gcc-arm-none-eabi-4_9-2015q3
失败的部分：
lpwif_get_slla(struct lpwif *lpwif, void *lla, unsigned char lla_len)
{
WpanDeviceP dev = lpwif->dev->wpan;
unsigned char len = 0;
if (lla_len >= 8) {
if (lpwif->eui[0] == 0xff) {
/* Fetch WPAN Device's Long Address. */
uint64_t addr64;
memset(&addr64, 0xff, sizeof(addr64));
WpanGet(dev, WpanPibAttr_macExtendedAddress, &addr64, 8);
/* Always return address in network-byte order */
lpwif->eui[0] = (addr64 >> 56) & 0xff;
lpwif->eui[1] = (addr64 >> 48) & 0xff;
lpwif->eui[2] = (addr64 >> 40) & 0xff;
lpwif->eui[3] = (addr64 >> 32) & 0xff;
lpwif->eui[4] = (addr64 >> 24) & 0xff;
lpwif->eui[5] = (addr64 >> 16) & 0xff;
lpwif->eui[6] = (addr64 >> 8) & 0xff;
lpwif->eui[7] = (addr64 >> 0) & 0xff;
}
if (lpwif->eui[0] == 0xff) return 0; /* Device has no EUI-64 address. */
if (lla) memcpy(lla, lpwif->eui, 8);
}
并且这个方法被`lpwif_get_slla(&state->lpwif, netif->hwaddr, 8);调用
反汇编：
if (lpwif->eui[0] == 0xff) return 0; /* Device has no EUI-64 address. */
10098ac: 6bfb ldr r3, [r7, #60] ; 0x3c
10098ae: f893 3024 ldrb.w r3, [r3, #36] ; 0x24
10098b2: 2bff cmp r3, #255 ; 0xff
10098b4: d101 bne.n 10098ba <lpwif_get_slla+0x10e>
10098b6: 2300 movs r3, #0
10098b8: e07f b.n 10099ba <lpwif_get_slla+0x20e>
if (lla) memcpy(lla, lpwif->eui, 8);
10098ba: 6bbb ldr r3, [r7, #56] ; 0x38
10098bc: 2b00 cmp r3, #0
10098be: d006 beq.n 10098ce <lpwif_get_slla+0x122>
10098c0: 6bfb ldr r3, [r7, #60] ; 0x3c
10098c2: 3324 adds r3, #36 ; 0x24
10098c4: 6bb8 ldr r0, [r7, #56] ; 0x38
10098c6: 4619 mov r1, r3
10098c8: 2208 movs r2, #8
10098ca: 4b3f ldr r3, [pc, #252] ; (10099c8 <lpwif_get_slla+0x21c>)
10098cc: 4798 blx r3
return 8;
10098ce: 2308 movs r3, #8
10098d0: e073 b.n 10099ba <lpwif_get_slla+0x20e>
【问题讨论】：
-
memcpy将为您处理对齐。一些 ARM CPU 能够进行非对齐访问。你确定你的构建和运行系统之间没有冲突吗？您能否提供正在使用的“C”代码 sn-p 以及发生未对齐异常的汇编程序列表。这些细节将帮助某人回答。如果您通过强制转换对对齐“撒谎”，那么编译可能会生成会导致“未对齐”异常的代码。 -
你能发布它失败的代码吗？
-
什么是
src，以及您是如何调用memcpy的（即此处未显示的代码中是否存在任何未定义的行为诱导指针转换）？另外，您使用的是什么实际版本的 GCC？ （我相信一些非常旧版本中的 ARM 后端有时会针对未对齐的加载/存储发出不正确的指令） -
很高兴看到导致错误的指令地址，以及导致错误的读取地址，但我猜调用
lpwif_get_slla()正在传递一个强制转换lpwif的指针（即一些非字对齐的缓冲区），当它得到lpwif->eui时，它正在尝试对非字对齐的地址和 barfing 执行 ldr。 -
嗯，相对最新的 GCC 4.9 可以很好地配置为默认针对 ARMv7。正如第一条评论所暗示的那样，如果您无意中让编译器认为可能未对齐的单字加载/存储很好，但是然后尝试在并非如此的情况下在 ARM9 或 Cortex-M0 之类的东西上运行，即使代码本身 100% 正确，这也可能导致问题。