[U-Boot] [PATCH v2] arm: Switch to -mno-unaligned-access when supported by the compiler

[Wolfgang Denk]

Dear Tom,

In message <20140210212630.GB7049 at bill-the-cat> you wrote:
> 
> Then gcc has a bug and you need to convince them to fix it.  What gcc
> does, as Mans has explained, and this invalidates the "lets catch
> unaligned access problems" notion, is for ARMv6 and higher say "we
> assume by default the hardware can perform native unaligned access, so
> make use of this in our optimization choices".

GCC for ARM has often perplexed me - I remember cases where it
generated 4 single-byte accesses to a u32 data type with perfectly
valid 32 bit alignment (like a device register).  Unfortunaltely I
never was able to have this considered a bug.  Everybody else thought
it was perfectly normal and it had always been like that (on ARM).

> But this part isn't true.  Or rather, it is (or may, at the whim of the
> compiler) catching every case where we say __attribute__((packed)) and
> then don't follow up ensuring that every access is then fixed up by
> hand, rather than letting the compiler do it.
>
> We've essentially picked "lets blow things up at times" over "lets keep
> an eye out for __packed being used in code, and be careful there".

I think many people use __packed without thinking.  Some code is just
horrible.  The fact that ARM code is full of examples where device I/O
is performed without compiler checking for data types is just an
indication.

I know this is bad, but do you see a way to make the compiler issue
clear warnings or errors for such "accidential" unaligned accesses?

> The problem is that __packed means we can see this problem whenever its
> used.  This is the design practice we need to be wary of, and make sure
> we're coding to an unfortunate reality rather than misoptimizing things.

__packed should be strictly forbidden everywhere except where mandated
by definitions for example of protocol implementations etc.  And even
there I tend to consider it wrong to use 32 or 16 bit types for data
fields that are misaligned (assum=ing the whole data structure is
properly aligned).

> > Regarding the EFI code, there was a patch submitted (see the thread you
> > have pointed me to) which had the proper unaligned access macros and
> > thus did not require -mno-unaligned-access for this file, and certainly
> > does not require it for the whole of ARM.
>
> Right, the EFI patch takes valid code and makes it differently valid.

Takes valid code?  But would this original code run on an architecture
where any unaligned access causes a machine check?  My understanding
is it doesn't?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I've got to get something inside me. Some coffee  or  something.  And
then the world will somehow be better.
                                     - Terry Pratchett, _Men at Arms_