Date: Sat, 26 Dec 2015 11:07:48 -0800 From: Mark Millard <markmi@dsl-only.net> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, mat@FreeBSD.org, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? Message-ID: <6EC8F626-D8C4-435E-B67A-CA841C9C1322@dsl-only.net> In-Reply-To: <1451149213.25138.271.camel@freebsd.org> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <DB75F0D6-86CB-4383-8653-6017C76729F9@dsl-only.net> <A338272B-982F-4E1F-B87D-1E33815EA212@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> <BBAAE33E-BD65-40A3-A0B3-F3346FC08112@dsl-only.net> <1451149213.25138.271.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2015-Dec-26, at 9:00 AM, Ian Lepore <ian@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. >>=20 >> 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. >=20 > 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). >=20 > -- Ian >=20 >=20 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 >=3D armv6 for = the kernel: = http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3D= 8428e84d42179c2a00f5f6450866e70d802d1d05 Interestingly clang -cc1 -help only mentions -mno-unaligned-access as a = note to -mstrict-align: > # clang++ -cc1 -help | grep align > -fmax-type-align=3D<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=3D<value> Specify the default maximum struct packing = alignment > -mstack-alignment=3D<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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6EC8F626-D8C4-435E-B67A-CA841C9C1322>