gt; I think this is fine.
>
Another thing that was suggested to me via private communication is to change
-Os
to -O1 for those "non-constrained" boot blocks. I do not see anything wrong
with
that.
--
Andriy Gapon
___
freebsd-current@free
On Monday, September 12, 2011 8:02:30 am Andriy Gapon wrote:
> > I think the patch is
> > fine, and I'd even prefer to go ahead and drop the extra cruft (like
> > removing
> > nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well.
>
> I personally agree, thank you for this su
on 12/09/2011 14:43 John Baldwin said the following:
> I suspect some of the recent changes to shave space down for Clang have made
> some of the optimization options no longer necessary.
Just a note of all the options in question were added long before clang.
> I think the patch is
> fine, and
l.
>
> Part I. ZFS and GPT bootblocks.
>
> I believe that we do not need here any extra optimizations and happy dances
> that
> seem to be carried over from boot2.
> I think that just the -Os should be sufficient of optimization flags. Maybe
> even that is not really req
oot2.
> I think that just the -Os should be sufficient of optimization flags. Maybe
> even that is not really required.
> Rationale:
> - these boot blocks are not as nearly space-constrained as boot2
> - using untypical flags increases chances of hitting compiler bugs,
> especiall
and happy dances that
seem to be carried over from boot2.
I think that just the -Os should be sufficient of optimization flags. Maybe
even that is not really required.
Rationale:
- these boot blocks are not as nearly space-constrained as boot2
- using untypical flags increases chances of hittin
On 05-Apr-99 Warner Losh wrote:
> In message <19990404232854.a5...@nuxi.com> "David O'Brien" writes:
>: Were you able to actually boot the bootblocks compiled with EGCS and -Os
>: ?
>: (I know the optimization gives us the space we need, but I'm not upto
>: testing new bootblocks at this moment)
>
In message <19990404232854.a5...@nuxi.com> "David O'Brien" writes:
: Were you able to actually boot the bootblocks compiled with EGCS and -Os ?
: (I know the optimization gives us the space we need, but I'm not upto
: testing new bootblocks at this moment)
To be honest, I didn't test them.
Warner
On 05-Apr-99 Jeroen Ruigrok/Asmodai wrote:
> On 05-Apr-99 David O'Brien wrote:
>>> Just wanted to let people know that the unmodified boot blocks have
>>> 144 bytes free if you compile them -Os and -16 free if you compile
>>> them -O2.
>>
>>
On 05-Apr-99 David O'Brien wrote:
>> Just wanted to let people know that the unmodified boot blocks have
>> 144 bytes free if you compile them -Os and -16 free if you compile
>> them -O2.
>
> Were you able to actually boot the bootblocks compiled with EGCS and -Os
In article <199904050513.xaa69...@harmony.village.org>,
Warner Losh wrote:
> -fno-exceptions didn't seem to impact things at all, nor
> did -fno-sjlj-exceptions. At least in terms of size.
That's because the default for C programs is -fno-exceptions. That
option still should be added to the M
> Just wanted to let people know that the unmodified boot blocks have
> 144 bytes free if you compile them -Os and -16 free if you compile
> them -O2.
Were you able to actually boot the bootblocks compiled with EGCS and -Os ?
(I know the optimization gives us the space we need, but I&#
Just wanted to let people know that the unmodified boot blocks have
144 bytes free if you compile them -Os and -16 free if you compile
them -O2. -fno-exceptions didn't seem to impact things at all, nor
did -fno-sjlj-exceptions. At least in terms of size. So it looks
like the right fix fo
On Mon, Jan 18, 1999 at 07:39:06PM +0200, Robert Nordier wrote:
> Josef Karthauser wrote:
>
> As the one who did the actual coding, I can confirm that the approach
> adopted in both the new bootblocks and the boot loader is virtually
> identical to that used in the older (biosboot) bootblocks. In
Steve Kiernan wrote:
>
> Okay, I did an update install with 3.0-STABLE (the snap from yesterday),
> but the new boot blocks weren't installed, so the old boot loader keeps
> complaining that the kernel is the wrong format (obviously, bootloader,
> it's an ELF kernel). An
Okay, I did an update install with 3.0-STABLE (the snap from yesterday),
but the new boot blocks weren't installed, so the old boot loader keeps
complaining that the kernel is the wrong format (obviously, bootloader,
it's an ELF kernel). Any way to get the new boot blocks onto the driv
Josef Karthauser wrote:
> We're having trouble using the new boot loader code and '-h' in
> boot.config. It appears that unless the terminal is connected to
> the serial port a machine doesn't reboot properly. My guess is
> that the new boot serial code is defaulting to hardware handshaking
> on
We're having trouble using the new boot loader code and '-h' in
boot.config. It appears that unless the terminal is connected to
the serial port a machine doesn't reboot properly. My guess is
that the new boot serial code is defaulting to hardware handshaking
on the serial terminal line, whereas
18 matches
Mail list logo
