When is an unaligned memory access illegal on ARM?
When is an unaligned memory access illegal on ARM?
- Subject: When is an unaligned memory access illegal on ARM?
- From: Jens Alfke <email@hidden>
- Date: Sun, 22 Jun 2014 11:05:23 -0700
I’m confused about unaligned memory accesses on ARM. My understanding was that they’re not allowed — that is, dereferencing a 32-bit value from a pointer that’s not four-byte aligned will crash. I’ve run into such crashes before. But right now I’ve got a situation where the Release build of an app crashes on an unaligned access, but the Debug build doesn’t! It’s the exact same place in the code — a CRC32 hash implementation — and I’ve verified that an odd address is being dereferenced (as a uint32*).
(This is a 32-bit process running on an iPhone 5, by the way.)
The only difference is in the assembly code generated. In the debug build it’s using ldr, while in the release build it’s using ldrd. (Apparently the optimizer is smart enough to realize that the next line of code is loading the next 4 bytes after the pointer, so it decides to combine both lines into a single instruction.)
So I’m guessing that ldr (a 32-bit load) allows unaligned access, but ldrd (64-bit) doesn’t?
Is there any comprehensive, up-to-date documentation about this? I’ve found an article from 2010* stating that unaligned accesses are supported but are slower because they trigger an OS trap (as on PPC); but it doesn’t say anything about ldrd.
There’s a StackOverflow Q&A about a crash with ldrd**, where the answer states that "ldrd needs the address to be 8-byte aligned”. But if that’s so, then I think the compiler optimization (-Ofast level) in my app was incorrect, because the value it’s dereferencing is a uint32_t*, so there’s no expectation that it's 8-byte aligned.
—Jens
* http://wanderingcoder.net/2010/07/19/ought-arm/
** http://stackoverflow.com/questions/7729107/crash-on-ios-device-when-dereferencing-a-pointer-returned-by-nscoders-decodebyt
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden