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 -- 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: w...@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_ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot