From owner-freebsd-stable@FreeBSD.ORG Fri May 11 08:09:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDAC91065678; Fri, 11 May 2012 08:09:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7E28FC15; Fri, 11 May 2012 08:09:20 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q4B897UY083402; Fri, 11 May 2012 11:09:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q4B896Zf001200; Fri, 11 May 2012 11:09:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q4B896P4001199; Fri, 11 May 2012 11:09:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 May 2012 11:09:06 +0300 From: Konstantin Belousov To: Andriy Gapon Message-ID: <20120511080906.GL2358@deviant.kiev.zoral.com.ua> References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FACB396.6060800@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K7v4p9QsotuTW/oA" Content-Disposition: inline In-Reply-To: <4FACB396.6060800@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, John Baldwin , Alfred Bartsch Subject: Re: i386 -march=xxx behavior [Was: FreeBSD 8 i386 gptboot corrupt - SOLVED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:09:20 -0000 --K7v4p9QsotuTW/oA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote: > on 09/05/2012 15:09 Alfred Bartsch said the following: > > Am 09.05.2012 12:42, schrieb Andriy Gapon: > >> on 09/05/2012 12:29 Alfred Bartsch said the following: > >>> This behavior is restricted to 32-bit servers (i386), all 64-bit=20 > >>> servers (amd64) work without any problem, as expected. > >>>=20 > >>> After some analyzing, it seems to me that the actual size of gptboot > >>> does matter (16723 bytes, >16kB). In amd64 environment (same source > >>> version) the actual size of /boot/gptboot is only 15443 bytes. > >=20 > >> Weird. Both amd64 and i386 builds should produce the same binaries as > >> the boot code is built with -m32 -march=3Di386 on amd64. But I can=20 > >> reproduce this, so it seems that the compilation is indeed done=20 > >> differently. > >=20 > >> Heh, it seems that it is -march=3Di386 flag that makes all the differe= nce. > >> Maybe we should use this flag even when doing native i386 builds... > >=20 > >=20 > > after adding "-march=3Di386" to CFLAGS in Makefile everything looks ok= =20 > > (filesize: 15443, as you predicted), so I would opt for using this flag= in > > the future. >=20 > Here is a small investigation into the -march flag. Not sure if it is of= any > practical significance, I just was curious. >=20 > First, seems that neither of i386/i486/i586/i686 values for this flag nor > absence of it implies features like MMX, SSE, and so on. (Saying this be= cause > of some assumptions about i686) >=20 > For the base GCC specifying -march with the above values is equivalent to > specifying -mtune with the same values, when mtune is not explicitly set. > Using "i686" or omitting the flag is equivalent to -mtune=3Dgeneric. >=20 > Note that this happens despite a FreeBSD-specific change to (base) GCC th= at > makes i486 a default arch. Derivation of the tune value from the arch va= lue, > if any, or defaulting it otherwise is done earlier than defaulting of the= arch > value. > Specifically I am talking about the block that deals with ix86_tune_string > that precedes the block for ix86_arch_string. >=20 > So it seems that at the moment our sys/boot code is effectively compiled = with > -mtune=3Dgeneric for i386 target (amd64 target has an explicit -march=3Di= 386 - I > wonder why not i486). >=20 > I think that in terms of instructions repertoire the difference is only in > availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring the > "system" instructions that should not be generated by a compiler from C c= ode). > And I guess that the sys/boot code is simple enough to not require these > instructions? > Otherwise, mtune seems to affect layout of the generated code and prefere= nce > for some instructions over others. >=20 > Again, not sure what conclusions can be made... -march=3Di686 also turns on use of cmov*. --K7v4p9QsotuTW/oA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+sySIACgkQC3+MBN1Mb4jxSgCdFSGMbh8P08s87b4LwDLT19wr KcEAoKcNxpqeL8szwWNSnn9X2tTRZx8R =07m4 -----END PGP SIGNATURE----- --K7v4p9QsotuTW/oA--