From owner-freebsd-current@FreeBSD.ORG Wed May 25 16:02:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 882621065672; Wed, 25 May 2011 16:02:44 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3383F8FC18; Wed, 25 May 2011 16:02:44 +0000 (UTC) Received: by iyj12 with SMTP id 12so9539001iyj.13 for ; Wed, 25 May 2011 09:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XM52JP5QFYZ0R/+Tv3iD4knSlNxmjRv6Ht3G5ptZITo=; b=hTJ5bBMQR+bJr2c83GRvLgEAAsjthjruq3CrVtyk/lGWz7wEvzSNcEoYCFmyHSlUdr idmJ4UA3KKOsCiO4Xvt/dp8jSRo/7bn98zo9rKqsuevB9HCu5I69IVMrNJFHBp39pNS0 ONx81tBHO7DkrAVvR7vJoVkPglHT7+JHkzEyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lTEsw3FkwXhk3RMwmU1REiXxVDYZc+3UCSdTtGe7HlFg10gmJDh1wRV6+AfY8+NBIE fMKIn5wlpLoOaeItnocHJFmwsmBUNORNZqqsw7YCqyUiiRwelJL/9kFjNpsoIyu6r404 98e9aOV0cbVTd+/00yRwfpbTkLao94ze1SZ6k= MIME-Version: 1.0 Received: by 10.42.159.66 with SMTP id k2mr6917066icx.344.1306339363734; Wed, 25 May 2011 09:02:43 -0700 (PDT) Received: by 10.42.177.10 with HTTP; Wed, 25 May 2011 09:02:43 -0700 (PDT) In-Reply-To: <201105250943.15362.jhb@freebsd.org> References: <1306267772-31084-1-git-send-email-lacombar@gmail.com> <4DDC17E5.2020700@FreeBSD.org> <201105250943.15362.jhb@freebsd.org> Date: Wed, 25 May 2011 12:02:43 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: [PATCH] Fix CFLAGS overwrite by Makefile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:02:44 -0000 Hi, On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: > On Tuesday, May 24, 2011 5:30:37 pm Arnaud Lacombe wrote: >> Hi, >> >> On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote: >> > On 2011-05-24 22:09, Arnaud Lacombe wrote: >> >> >> >> Many Makefile (espectially under sys/boot/) overwrite the value of > CFLAGS. >> >> This is an issue if you want to generate code for a specific CPU as > before >> >> the >> >> Makefile is interpreted, CFLAGS might already have been set with CPU >> >> specific >> >> settings by, which is source from sys.mk. >> > >> > ... >> >> >> >> --- a/sys/boot/i386/boot2/Makefile >> >> +++ b/sys/boot/i386/boot2/Makefile >> > >> > ... >> > >> > The problem with this patch is that for some of the things you fixed, >> > stuff like boot-time programs, you NEVER want any CPU specific setting= s! >> > You must use the default, lowest common denominator setting instead, o= r >> > there is no guarantee the boot program will be correct. >> > >> To use your argument against you: with the default, the boot program >> is not correct (see below). > > Thousands of machines succesfully booting FreeBSD would seem to contradic= t > your assertion. > my assertion is backed by experiment, so I'm fine with the contradiction. >> > So that is why these Makefiles purposefully overwrite CFLAGS. it is no= t >> > by accident. >> You just might be right, but unless the code say the overwrite is >> _on_purpose_, I would not assume the state of mind of the author, one >> way or another. > > The boot code is certainly intended to be something that works across the > board. =A0Also, I doubt you will see any user-visible performance differe= nce > from changing the optimization options for the boot code. > Saving a few kilobytes of space might be more important than speed in some environment. >> > Besides, for space-constrained things like boot2, you >> > might not even be able to compile it when using non-standard settings, >> > since the code might grow too large. >> > >> or can shrink by using more optimized instructions. > > Well, your test in a later e-mail is a bit flawed. =A0GCC tends to insert > a lot of padding for newer CPUs to align things on more optimal boundarie= s. > That does not explain at all why the default setting always produces the worst code, size-wise. > We run 'sed' over the assembly version of boot2 to strip all that out. > ... to save 4 bytes. > However, the more important point for the boot code is that it needs to > just work. > and it does not, because gcc defaults are _bad_. - Arnaud