From owner-svn-src-head@FreeBSD.ORG Thu Mar 8 19:57:18 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 010D2106566C for ; Thu, 8 Mar 2012 19:57:18 +0000 (UTC) (envelope-from dchisnall@pathscale.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE0D8FC12 for ; Thu, 8 Mar 2012 19:57:17 +0000 (UTC) Received: by eekd17 with SMTP id d17so279394eek.13 for ; Thu, 08 Mar 2012 11:57:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FecBPFE5szP5zFoXHadRD3idtPehnZnW1M99hZHjMBI=; b=BDa7eOZ0ix3A9Ilomysk8zV407ju58PnewB5V64+ZaDNtQWXT0n0jgU3CtcPq5vngd sNgAYW4yD9+t1sNvp4ji92IRmnoJtQmN/8x8l9wkVRGQz+KBPZ8eSYMFjaCpxSLEKZdp RRMfSJ47zV+z5bh4K8e0Fl2ENZaLfRZI7s5S+WLEqPE3N3W1jdL3acZC1xL0ZdeF2veC HVJbZ15yXkEpnSgHpXYtun4tlokeCYW6yG1bRTtlNI9EbSZnw6PcDT5x5S56STYhi9i1 VC8n9zztsR971Tmbl7IrU7H8A/d+GwZGdnXbiG5jMcYIzAr/JODCcrR9WeEu6W1a1wLM xONA== Received: by 10.213.105.147 with SMTP id t19mr3639ebo.170.1331235131199; Thu, 08 Mar 2012 11:32:11 -0800 (PST) Received: from [192.168.0.2] (cpc1-cwma8-2-0-cust257.7-3.cable.virginmedia.com. [82.20.153.2]) by mx.google.com with ESMTPS id h47sm9432016eea.10.2012.03.08.11.32.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:32:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <201203081105.32334.jhb@freebsd.org> Date: Thu, 8 Mar 2012 19:32:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <09C8D743-8295-4F92-9332-D83F73B5F86D@FreeBSD.org> References: <201203051953.q25JrIS1002269@svn.freebsd.org> <201203071700.21259.jkim@FreeBSD.org> <201203081105.32334.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl01+dxxnw2V0bKdQoo2lNlGDBduMFeohSzuoX36zryOZC6XG5u4Qm+YON/pfoxk6NabMym Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers@FreeBSD.org, Jung-uk Kim Subject: Re: svn commit: r232570 - head/sys/boot/i386/boot2 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:57:18 -0000 On 8 Mar 2012, at 16:05, John Baldwin wrote: > On Wednesday, March 07, 2012 5:00:19 pm Jung-uk Kim wrote: >> On Monday 05 March 2012 02:53 pm, John Baldwin wrote: >>> Author: jhb >>> Date: Mon Mar 5 19:53:17 2012 >>> New Revision: 232570 >>> URL: http://svn.freebsd.org/changeset/base/232570 >>>=20 >>> Log: >>> Fix boot2 to handle boot config files that only contain a custom >>> path to a loader or kernel. Specifically, kname cannot be pointed >>> at cmd[] since it's value is change to be an empty string after the >>> initial call to parse, and cmd[]'s value can be changed (thus >>> losing a prior setting for kname) due to user input at the boot >>> prompt. While here, ensure that that initial boot config file text >>> is nul-terminated, that ops is initialized to zero, and that kname >>> is always initialized to a valid string. >>=20 >> As many people pointed out, Clang overflows boot2 again after this=20 >> commit. Long long time ago, I asked this question on arch@: >>=20 >> http://docs.freebsd.org/cgi/mid.cgi?200509081418.47794.jkim >>=20 >> Why can't we do that now? Can't we build separate ufs1-only and=20 >> ufs2-only boot2's, at least? Having ufs1+ufs2 boot block is great=20 >> but I see very little benefit to support that in 2012. :-/ >=20 > As I said on the reply to current@, I think having separate boot = blocks will=20 > be a headache and PITA for our users. Let's see if we can get boot2 = to fit=20 > without breaking functionality first. It is a shame that gcc = outperforms=20 > clang so drastically in this case (gcc's boot2 is about 250 bytes = smaller than=20 > clang's). I'm going to take a look at the sequence of optimisations that are run = with -Os. It's currently mostly the same as -O2, which is probably not = ideal. I'll also see if I can create a .ll from boot2 that we can add = to the LLVM unit tests so that anyone who pushes it over the size = boundary will get a buildbot failure. David=