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

Wolfgang Denk
2014-02-11T08:19:09Z

Dear Tom,

In message <20140210222819.GE7049@bill-the-cat> you wrote:
>
> I agree we shouldn't use __packed without a good reason. And I don't
> think we've got many no-reason uses right now but I'm all in favor of
> dropping them and keeping an eye on new users. The problem is that
> unless we do something, any of the valid and we aren't going to / can't
> change them __packed structs will be the next place things blow up when
> gcc optimizes things in a new (and valid based on what we've told it!)
> way.

If I look around where __packed (and variants) is being used I could
just cry. Just have a loog for example at include/ec_commands.h - it
appears they always add __packed to all structs, including such where
all entries are uint8_t - see for example struct ec_lpc_host_args :-(

> > 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?
>
> It would run because being __packed gcc would know to do the right thing
> on that architecture.

We are not discussing application code here. We are dealing with low-
level hardware related stuff. When I try to read from a 32 bit device
register I must be absolutley sure that this will be a single 32 bit
transfer. It is totally unacceptable if I have to fear that the
compiler might break this up into 4 byte accesses behind my back. What
if this happens to be an auto-incrementing register or such?

But obviously only few people share this point of view...

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
Man did not weave the web of life; he is merely a strand in it.
Whatever he does to the web, he does to himself. - Seattle [1854]