Re: When is an unaligned memory access illegal on ARM?
Re: When is an unaligned memory access illegal on ARM?
- Subject: Re: When is an unaligned memory access illegal on ARM?
- From: Erik Schwiebert <email@hidden>
- Date: Sun, 22 Jun 2014 18:55:12 +0000
- Thread-topic: When is an unaligned memory access illegal on ARM?
I believe ARM requires 8-byte loads (ldrd, or doubles into the FPU, etc) require 8-byte alignment and will crash otherwise. 4-byte loads do not require alignment but will be slower if the pointer is not 4-byte aligned. It will not crash though.
Sent from my iPhone.
> On Jun 22, 2014, at 11:06 AM, "Jens Alfke" <email@hidden> wrote:
>
> 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
_______________________________________________
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