[U-Boot] static var mem alignment issue/question

[Måns Rullgård]

Tim Harvey <tharvey at gateworks.com> writes:

> On Tue, Nov 29, 2016 at 4:06 AM, Måns Rullgård <mans at mansr.com> wrote:
>> Tim Harvey <tharvey at gateworks.com> writes:
>>
>>> Greetings,
>>>
>>> In debugging an issue with a rather old branch of U-Boot (2015-04) I
>>> found that the static assignment of a data buffer was not 32-bit
>>> aligned which caused data aborts. However I find that current U-boot
>>> master does not suffer this issue and no matter what I declare static
>>> before the particular variable its always 32-bit aligned. I don't see
>>> any code changes that would cause this and in both cases I'm building
>>> with the same gcc5.2.0 toolchain.
>>>
>>> The code in question is this this from cmd/fdt.c:
>>>
>>>         } else if (argv[1][0] == 's') {
>>>                 char *pathp;            /* path */
>>>                 char *prop;             /* property */
>>>                 int  nodeoffset;        /* node offset from libfdt */
>>>                 static char data[SCRATCHPAD];   /* storage for the property */
>>>                 int  len;               /* new length of the property */
>>>                 int  ret;
>>>
>>> What guarantee's that 'data' above is 32-bit aligned in master that is
>>> missing from the older U-Boot branch I'm using? Perhaps there is some
>>> arg in a Makefile that I'm missing?
>>
>> There are no such guarantees.  Things often end up 4-byte aligned by
>> chance simply because most of them are a multiple of 4 bytes in size.
>> The code should be fixed, either by explicitly aligning the buffer or by
>> using the put_unaligned_b32() accessor in fdt_parse_prop().  Here's an
>> untested patch:
>
> Måns,
>
> My thoughts as well but what I found on a 2015.04 U-Boot adding a
> 'static char foo[1]' before the 'static char data[SCRATCHPAD]' and
> printing the addrs:
> foo:4ff9e0b2
> data:4ff9e0b3
> (what I would have expected... no alignment guarantees and clearly not
> quad-byte aligned)
>
> The same change on master:
> foo:4ff9fff4
> data:4ff9fbf0
> (not at all what I expected - quad byte aligned and more)
>
> Thus I figured there was something in a Makefile that was directing
> the compiler (same compiler in both cases)
>
> I find that merely including '<asm/unaligned.h>' (with no code
> changes) changes the alignment and aligns propery???

Compilers are fickle creatures.

-- 
Måns Rullgård