svn commit: r232570 - head/sys/boot/i386/boot2

[David Chisnall]

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
>>> 
>>> 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.
>> 
>> As many people pointed out, Clang overflows boot2 again after this 
>> commit.  Long long time ago, I asked this question on arch@:
>> 
>> http://docs.freebsd.org/cgi/mid.cgi?200509081418.47794.jkim
>> 
>> Why can't we do that now?  Can't we build separate ufs1-only and 
>> ufs2-only boot2's, at least?  Having ufs1+ufs2 boot block is great 
>> but I see very little benefit to support that in 2012. :-/
> 
> As I said on the reply to current@, I think having separate boot blocks will 
> be a headache and PITA for our users.  Let's see if we can get boot2 to fit 
> without breaking functionality first.  It is a shame that gcc outperforms 
> clang so drastically in this case (gcc's boot2 is about 250 bytes smaller than 
> 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