Tim Harvey tharvey@gateworks.com writes:
On Tue, Nov 29, 2016 at 4:06 AM, Måns Rullgård mans@mansr.com wrote:
Tim Harvey tharvey@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.