[U-Boot] [RFC] [PATCH] rewrite doc/README.arm-unaligned-accesses

[Tom Rini]

On Sat, Feb 22, 2014 at 01:17:50PM +0100, Albert ARIBAUD wrote:

[snip]
> Again -- I do insist -- I understand your viewpoint, which is that
> compilers can always be made to produce correct code from packed structs
> with unaligned fields, therefore such unaligned fields are not a
> problem and we should just let the compilers deal with it by passing
> them adequate options, which in the case of ARM means pasing gcc
> "-mno-unaligned-access" at least when it is not the default already.

OK, good.  I made a mistake when I accepted the ARM change that moved us
away from -mno-unaligned-access + -march=armv7 (or armv6 but we don't
have that tune atm).  To be clear, our project policy is not a strict
C99 implementation.  We use that to guide us in many cases (and frankly,
we may let C11 guide us as needed and things mature).  We rely upon
certain gcc behaviors.  In this case we rely on access to packed structs
and unaligned members working seamlessly.  ARM must be corrected to work
here as all other architectures do.

> And I would agree with this viewpoint if I did not want us to catch
> unaligned accesses in the source code which we don't know about yet.

This is wrong.  Every case we see on ARMv7 now is the case of "compiler
was told unaligned access needs no special handling, perform no special
handling here".  For _all_ architectures gcc would look at this code and
then based on what it's been told about CPU capabilities make a decision
that it believes would not lead to a fault.

> My viewpoint is that not all unaligned accesses are wanted, and we
> should catch those that we did not and either remove them or make them
> explicit. And I think that is the gist of the kernel doc -- if relying
> on the compiler was enough, put/get_unaligned would not be suggested.

No, this isn't quite right.  The gist of the kernel doc is that there
are some cases where the compiler cannot know if the addresses will be
aligned or not, and _those_ require special care.  Most cases however
the compiler does take care to align pointers or break down the accesses
when it can know things are unaligned.

[snip]
> The way I see it, if we follow the kernel doc advice of always making
> unaligned accesses explicit in the source code (and we should), then
> -munaligned-access only has advantages over -mno-unaligned-access,
> because both behave the same way for wanted unaligned accesses, but
> -munaligned-access will catch unwanted ones whereas
> -mno-unaligned-access won't.

This glosses over the very important part where, in short, "__packed
structs may look dangerous at first glance, but they aren't", with
respect to the constraints the kernel (and ourself) place upon the
compiler.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140224/0b84b0b4/attachment.pgp>