From owner-freebsd-toolchain@freebsd.org Sat Dec 26 17:00:22 2015 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DED86A5251B for ; Sat, 26 Dec 2015 17:00:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAC7C1396 for ; Sat, 26 Dec 2015 17:00:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 26 Dec 2015 16:59:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBQH0DWq010253; Sat, 26 Dec 2015 10:00:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1451149213.25138.271.camel@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? From: Ian Lepore To: Mark Millard , Warner Losh Cc: mat@FreeBSD.org, freebsd-arm , FreeBSD Toolchain Date: Sat, 26 Dec 2015 10:00:13 -0700 In-Reply-To: References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@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> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 17:00:23 -0000 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