On 2015-Dec-26, at 9:00 AM, Ian Lepore <i...@freebsd.org> wrote: > On Fri, 2015-12-25 at 17:21 -0800, Mark Millard wrote: >> In my view "-mno-unaligned-access" is an even bigger hammer than I >> used. I find no clang statement about what its ABI consequences would >> be, unlike for what I did: What mix of more padding for alignment vs. >> more but smaller accesses? But as I remember I've seen "-mno >> -unaligned-access" in use in ports and the like so its consequences >> may be familiar material for some folks. >> >> Absent any questions about ABI consequences "-mno-unaligned-access" >> does well mark the expected SCTLR bit[1] status, far better than what >> I did. Again: I was covering my ignorance while making any >> significant investigation/debugging as unlikely as I could. > > After reading the docs more carefully, I think -mno-unaligned-access > isn't a bigger hammer, it's just a different tool that addresses a > different problem than the one you ran into, and it's one we need. In > particular, it prevents alignment-required accesses to potentially > unaligned fields in a struct marked as 'packed', which is something we > rely on (it's why we mark some structs as packed). > > -- Ian > >
If clang uses the same interpretation as gcc for arm then I agree: > -munaligned-access > -mno-unaligned-access > Enables (or disables) reading and writing of 16- and 32- bit values from > addresses that are not 16- or 32- bit aligned. By default unaligned access is > disabled for all pre-ARMv6 and all ARMv6-M architectures, and enabled for all > other architectures. If unaligned access is not enabled then words in packed > data structures are accessed a byte at a time. I see that linux went with SCTLR bit[1] being cleared for >= armv6 for the kernel: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8428e84d42179c2a00f5f6450866e70d802d1d05 Interestingly clang -cc1 -help only mentions -mno-unaligned-access as a note to -mstrict-align: > # clang++ -cc1 -help | grep align > -fmax-type-align=<value> > Specify the maximum alignment to enforce on > pointers lacking an explicit alignment > -fno-bitfield-type-align > Ignore bit-field types when aligning structures > -fpack-struct=<value> Specify the default maximum struct packing alignment > -mstack-alignment=<value> > Set the stack alignment > -mstackrealign Force realign the stack at entry to every function > -mstrict-align Force all memory accesses to be aligned (same as > mno-unaligned-access) Also -munaligned-access is not mentioned at all. Apparently "clang -cc1 -help" does not generally document gcc compatibility syntax. gcc's AArch64 page https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options only mentions -mstrict-align : "Do not assume that unaligned memory references are handled by the system". (Not as explicit for interpretation as the earlier-quoted arm wording.) gcc's arm page https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options only mentions -munaligned-access and -mno-unaligned-access (as quoted earlier), not -mstrict-align . powerpc's page at https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options only mentions -mstrict-align and -mno-strict-align : "On System V.4 and embedded PowerPC systems do not (do) assume that unaligned memory references are handled by the system". It looks like being compatible for the command line syntax requires separate cases across architectures, especially when spanning both clang and gcc. _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
