Dear Tom,
In message 20140210212630.GB7049@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