Hi Tom, On Mon, 10 Feb 2014 08:21:39 -0500, Tom Rini <tr...@ti.com> wrote:
> On Mon, Feb 10, 2014 at 10:24:47AM +0100, Albert ARIBAUD wrote: > > Hi Tom, > > > > On Tue, 4 Feb 2014 12:05:33 -0500, Tom Rini <tr...@ti.com> wrote: > > > > > When we tell the compiler to optimize for ARMv7 it assumes a default of > > > unaligned accesses being supported at the hardware level and can make > > > use of this to perform what it deems as an optimization in any case, > > > including allowing for data to become unaligned. We explicitly disallow > > > this hardware feature so we must tell the compiler. > > > > > > Cc: Albert ARIBAUD <albert.u.b...@aribaud.net> > > > Cc: Mans Rullgard <m...@mansr.com> > > > Signed-off-by: Tom Rini <tr...@ti.com> > > > > NAK -- the discrepancy between the compiler being told to allow native > > unaligned accesses while at the same time telling the hardware to trap > > them is conscious and voluntary. It was chosen to help detect unaligned > > accesses which are rarely necessary and can be explicitly performed by > > software on a case by case basis. > > > > If and when a specific file requires unaligned access which cannot be > > made by some other mean than enabling -mno-unaligned-access, then this > > file should have it added, not the whole of U-Boot. > > Right, I recall the discussion, and we chose wrong. I am quite prepared to discuss whether we chose wrong or right, and to change my mind when the conditions are right, but I'll need more than such a short and simple statement. :) > We aren't being clever and making problems that would appear on armv5 > and lower (or non-ARM never allows unaligned access platforms) problems > to appear on more common armv7 platforms. Agreed that we are making problems appear on ARMv7 which are not that much of an issue on ARMv7, but are a true issue on non-ARMv7 arches; that *is* the intent. We want to know as early as possible when some code which runs ok on unaligned-access-friendly platforms such as ARMv7 might cause trouble on unaligned-access-adverse platforms later, once it gets used there too. > We're telling the compiler it's OK to do > one thing when it's not and then getting annoying problems such as the > EFI partition one where the compiler looks at everything, says we can do > $this and then fails at runtime because we lied to it. The whole > splashguard set of options is another place where I believe we've shot > ourselves in the foot, quite likely. Ok, so the cause of this patch is not the apparent contradiction between the compiler and hardware setting per se; it is that the EFI code has issues which make it susceptible to crash on unaligned-access-adverse platforms. This means the trap has worked as expected and has caught some code which does unaligned accesses. Let's analyze it: either we'll conclude it can and should be fixed through e.g. ad hoc unaligned access macros or we'll conclude it can't and we'll add -mno-unaligned-access to the files which can't work otherwise. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
