Re: Unexpected unaligned access on arm

[Andrew Haley <aph@redhat.com>]

On 09/06/2020 09:05, Lars Poeschel wrote:
> On Mon, Jun 08, 2020 at 10:49:22PM +0900, Oleg Endo wrote:
>> On Mon, 2020-06-08 at 15:34 +0200, Lars Poeschel wrote:
>>>
>>> What am I missing ? What am I doing wrong ?
>>>
>>
>> You're casting an address of some byte array to a point to struct,
>> which has an alignment > 1 byte.  Try adding a #pragma pack (1) or
>> respective attribute.
>
> Thank you! The pragma does indeed the right thing. gcc now produces
> code, that accesses the fields in question individually.
> But shouldn't the option
> -mno-unaligned-access
> I use for compiling also do the same ?

No.

'-munaligned-access'
'-mno-unaligned-access'
     Enables (or disables) reading and writing of 16- and 32- bit values
     from addresses that are not 16- or 32- bit aligned.  By default
     unaligned access is disabled for all pre-ARMv6, all ARMv6-M and for
     ARMv8-M Baseline architectures, and enabled for all other
     architectures.  If unaligned access is not enabled then words in

-mno-unaligned-access tells the compiler not to generate accesses to
unaligned words. In this test case, the compiler didn't generate the
unaligned access, *you* did. You did this by casting the address of an
unaligned byte array to the address of a struct.

If you take the address of a struct, cast it to a char*, then cast it
back to a pointer to the struct type, that'll work. Likewise if you
cast the result of malloc() to any struct pointer.

  If you lie to the compiler, it will get its revenge.
    - Henry Spencer

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671