From owner-svn-src-all@FreeBSD.ORG Sat Jan 3 16:24:28 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 716359FD; Sat, 3 Jan 2015 16:24:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4576D10CC; Sat, 3 Jan 2015 16:24:27 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y7RUz-0009sY-7Q; Sat, 03 Jan 2015 16:24:21 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t03GOJft003931; Sat, 3 Jan 2015 09:24:19 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19rrnfjYhw+XSrrWrkij7YE Message-ID: <1420302259.85983.26.camel@freebsd.org> Subject: Re: svn commit: r276596 - in head/sys/arm: arm include From: Ian Lepore To: Bruce Evans Date: Sat, 03 Jan 2015 09:24:19 -0700 In-Reply-To: <20150103184754.H1159@besplex.bde.org> References: <201501022346.t02NkRgd032775@svn.freebsd.org> <20150103184754.H1159@besplex.bde.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 16:24:28 -0000 On Sat, 2015-01-03 at 19:34 +1100, Bruce Evans wrote: > On Fri, 2 Jan 2015, Ian Lepore wrote: > > > Log: > > Fix alignment directives in arm asm code after clang 3.5 import. > > > > The ancient gas we've been using interprets .align 0 as align to the > > minimum required alignment for the current section. Clang's integrated > > assembler interprets it as align to a byte boundary. Fortunately both > > assemblers interpret a non-zero value as align to 2^N so just make sure > > we have appropriate non-zero values everywhere. > > > Modified: head/sys/arm/arm/bcopyinout.S > > ============================================================================== > > --- head/sys/arm/arm/bcopyinout.S Fri Jan 2 23:27:16 2015 (r276595) > > +++ head/sys/arm/arm/bcopyinout.S Fri Jan 2 23:46:26 2015 (r276596) > > @@ -52,7 +52,7 @@ __FBSDID("$FreeBSD$"); > > #else > > > > .text > > - .align 0 > > + .align 2 > > This is still confusing. > > Doesn't clang on arm support .p2align? On x86, '.align N' means align to > boundary N, where N must be a power of 2. Alignment to boundary 2**N > can be done by expanding 2**N literally or using '.p2align N'. The latter > is better, and is always (?) used in FreeBSD sources. It was also > generated by gcc-3.3.3. gcc-4 broke this and generates .align, and clang > is bug for bug compatible with the newer gcc. > > .align used to mean power of 2 alignment on x86 too, but gas changed this > in 1995, or at least introduced .p2align then: When I was searching for info on this yesterday what I found was some old mail threads in various toolchain developer venues in which it was mentioned that x86 is the odd one for .align taking a byte count that must be a power of 2 and all other platforms have always had the 2**N interpretation. I also think arm was odd in its interpretation of .align 0; other platforms interpret it as byte-alignment. It leaves arm with no way to change from an alignment of >1 to 1, so this reinterpretation by the clang authors, while a bit inconvenient for old code, seems sensible. I was also thinking that maybe a good solution to this would be ALIGN_TEXT and ALIGN_DATA macros to consolidate the yuck into one place, but that's a project for another day, yesterday I just wanted to get the arm world working again. Before I start adding new macros I really want to investigate the possibilty of using real asm macros instead of CPP, if I can find a useful intersection of syntaxes between the various tools we have to use. -- Ian