Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-04-17 Thread Craig Rodrigues
On Sat, Mar 28, 2015 at 4:05 PM, Craig Rodrigues rodr...@freebsd.org
wrote:

 Hi,

 To work around the problems build rescue, this time I used a build host
 running FreeBSD-CURRENT at svn revision r280353

 I took this patch for libc++ and applied it to my tree:

 http://reviews.llvm.org/D8461

 I used this script to build with gcc 4.9:


 https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh

 Buildling sys/i386/boot2 failed:

 === sys/boot/i386/boot2 (all)
 objcopy -S -O binary boot1.out boot1
 dd if=/dev/zero of=boot2.ldr bs=512 count=1
 1+0 records in
 1+0 records out
 512 bytes transferred in 0.34 secs (14989607 bytes/sec)
 /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
 /usr/obj/opt2/branches/head/tmp/usr/include
 -L/usr/obj/opt2/branches/head/tmp/usr/lib
 --sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
 -fomit-frame-pointer  -mrtd  -mregparm=3  -DUSE_XREAD  -DUFS1_AND_UFS2
 -DFLAGS=0x80  -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600
 -I/opt2/branches/head/sys/boot/i386/boot2/../../common
 -I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I.  -Wall
 -Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-declarations
 -Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow
 -Wstrict-prototypes -Wwrite-strings  -Winline -march=i386 -ffreestanding
 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32
 -std=gnu99-Os  -fno-guess-branch-probability  -fno-unit-at-a-time
 --param max-inline-insns-single=100 -mpreferred-stack-boundary=2  -S -o
 boot2.s.tmp /opt2/branches/head/sys/boot/i386/boot2/boot2.c
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'parse':
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:484:6: warning: suggest
 parentheses around assignment used as truth value [-Wparentheses]
   if (k = ep - arg) {
   ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'load':
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:334:9: warning: called
 from here [-Winline]
  if (xfsread(ino, hdr, sizeof(hdr)))
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:341:6: warning: called
 from here [-Winline]
   if (xfsread(ino, p, hdr.ex.a_text))
   ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:344:6: warning: called
 from here [-Winline]
   if (xfsread(ino, p, hdr.ex.a_data))
   ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:349:10: warning: called
 from here [-Winline]
   if (xfsread(ino, ep + j, sizeof(ep[0])))
   ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:357:10: warning: called
 from here [-Winline]
   if (xfsread(ino, p, ep[i].p_filesz))
   ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:365:10: warning: called
 from here [-Winline]
   if (xfsread(ino, es, sizeof(es)))
   ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
 failed in call to 'xfsread': call is unlikely and code size would grow
 [-Winline]
  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
  ^
 /opt2/branches/head/sys/boot/i386/boot2/boot2.c:371:7: warning: called
 from here [-Winline]
if (xfsread(ino, p, es[i].sh_size))
^
 sed -e '/align/d' -e '/nop/d'  boot2.s.tmp  boot2.s
 rm -f boot2.s.tmp
 /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
 /usr/obj/opt2/branches/head/tmp/usr/include
 -L/usr/obj/opt2/branches/head/tmp/usr/lib
 --sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
 -m32 -c boot2.s
 /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
 /usr/obj/opt2/branches/head/tmp/usr/include
 -L/usr/obj/opt2/branches/head/tmp/usr/lib
 --sysroot=/usr/obj/opt2/branches/head/tmp 

Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Warner Losh

 On Mar 29, 2015, at 6:37 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 
 On Mar 29, 2015, at 15:56, Warner Losh i...@bsdimp.com wrote:
 
 On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote:
 
 If we built a UFS1-only boot2, that would fit in the 7.5k we have left
 to play with. We could then build a UFS2-only boot2 that would easily
 fit in the like 32k limit that UFS2 has.
 
 The only reason we went to supporting both was to have something
 universal. Since it requires a reformat to go from UFS1 - UFS2 we
 wanted the transition to be as smooth as possible so you didn’t have
 to add boot blocks into the mix.
 
 Now the only people that use UFS1 are people with really old systems
 that are never going to upgrade, or people building new systems with
 UFS1 because they are space constrained (for whatever reasons that
 we’re not going to debate here: they are still real).
 
 In the past 5 years, I have worked on some embedded systems where UFS1 was 
 chosen because of very low memory and disk space requirements.
 So those systems are real and out there.
 
 Just out of curiousity, what is it about newer compilers that cause
 the size of boot2 to increase so much?
 
 Could we do some silly things like removing/reducing the use of printf()
 to save some more bytes, in order to buy us more time, before having
 to rewrite everything? :)
 
 Removing printf isn’t going to save us. It usually compiles to 80-120 bytes.
 
 I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe
 some safety belts in the boot block splatter programs to prevent
 brickification.
 
 Since the proposal to split up the code by filesystems is on the table, would 
 it make sense to do something similar for zfs?
 Thanks!

zfs isn’t in boot2 by default, just ufs1 and ufs2, so I on’t understand the 
question.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Garrett Cooper

 On Mar 29, 2015, at 15:56, Warner Losh i...@bsdimp.com wrote:
 
 On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote:
 
 If we built a UFS1-only boot2, that would fit in the 7.5k we have left
 to play with. We could then build a UFS2-only boot2 that would easily
 fit in the like 32k limit that UFS2 has.
 
 The only reason we went to supporting both was to have something
 universal. Since it requires a reformat to go from UFS1 - UFS2 we
 wanted the transition to be as smooth as possible so you didn’t have
 to add boot blocks into the mix.
 
 Now the only people that use UFS1 are people with really old systems
 that are never going to upgrade, or people building new systems with
 UFS1 because they are space constrained (for whatever reasons that
 we’re not going to debate here: they are still real).
 
 In the past 5 years, I have worked on some embedded systems where UFS1 was 
 chosen because of very low memory and disk space requirements.
 So those systems are real and out there.
 
 Just out of curiousity, what is it about newer compilers that cause
 the size of boot2 to increase so much?
 
 Could we do some silly things like removing/reducing the use of printf()
 to save some more bytes, in order to buy us more time, before having
 to rewrite everything? :)
 
 Removing printf isn’t going to save us. It usually compiles to 80-120 bytes.
 
 I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe
 some safety belts in the boot block splatter programs to prevent
 brickification.

Since the proposal to split up the code by filesystems is on the table, would 
it make sense to do something similar for zfs?
Thanks!
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Roman Divacky
  I used this script to build with gcc 4.9:
  
  https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
  
  Buildling sys/i386/boot2 failed:
 ...
  output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0
  -1007 bytes available
  *** Error code 1
 
 Oof, this is going to be hard to fix.  For some reason, boot2 is one of
 those programs that keeps getting worse (i.e. larger) with *each* new
 compiler version, be it gcc or clang!
 
 The last few times when we imported a new clang version, we had to jump
 through several hoops, and attempted to shrink the code again with
 various cleanups.  Even then, we don't have a lot of headroom.
 
 If it is now also becoming a problem with gcc 4.9, we should really
 start looking for a more permanent solution, e.g.:
 * Getting rid of the 7680 byte limit (seems to be impossible?)
 * Rewrite most of (or all of) boot2 in assembly

We can also get rid of UFS1 support... That shrinks the code a lot.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org


Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Warner Losh

 On Mar 29, 2015, at 2:27 AM, Roman Divacky rdiva...@freebsd.org wrote:
 
 I used this script to build with gcc 4.9:
 
 https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
 
 Buildling sys/i386/boot2 failed:
 ...
 output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0
 -1007 bytes available
 *** Error code 1
 
 Oof, this is going to be hard to fix.  For some reason, boot2 is one of
 those programs that keeps getting worse (i.e. larger) with *each* new
 compiler version, be it gcc or clang!
 
 The last few times when we imported a new clang version, we had to jump
 through several hoops, and attempted to shrink the code again with
 various cleanups.  Even then, we don't have a lot of headroom.
 
 If it is now also becoming a problem with gcc 4.9, we should really
 start looking for a more permanent solution, e.g.:
 * Getting rid of the 7680 byte limit (seems to be impossible?)
 * Rewrite most of (or all of) boot2 in assembly
 
 We can also get rid of UFS1 support... That shrinks the code a lot.

No we can’t. And that’s kinda the useless decision to make if you look
at where the 8k limit comes from.

UFS1 imposes the 8k limit. UFS2 has no such limit, but there’s some
issues with some old installs listing 8k as the size to fit into the disklabel
reserves of the time.

If we built a UFS1-only boot2, that would fit in the 7.5k we have left
to play with. We could then build a UFS2-only boot2 that would easily
fit in the like 32k limit that UFS2 has.

The only reason we went to supporting both was to have something
universal. Since it requires a reformat to go from UFS1 - UFS2 we
wanted the transition to be as smooth as possible so you didn’t have
to add boot blocks into the mix.

Now the only people that use UFS1 are people with really old systems
that are never going to upgrade, or people building new systems with
UFS1 because they are space constrained (for whatever reasons that
we’re not going to debate here: they are still real).

All typical installs are UFS2.

As such, with a bit of automation in our boot block writing, and we should
be in good shape.

So no, we can’t get rid of UFS1 support and have all our problems be
solved. However, we likely can solve most of the issues by moving away
from a single image.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Craig Rodrigues
On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote:


 If we built a UFS1-only boot2, that would fit in the 7.5k we have left
 to play with. We could then build a UFS2-only boot2 that would easily
 fit in the like 32k limit that UFS2 has.

 The only reason we went to supporting both was to have something
 universal. Since it requires a reformat to go from UFS1 - UFS2 we
 wanted the transition to be as smooth as possible so you didn't have
 to add boot blocks into the mix.

 Now the only people that use UFS1 are people with really old systems
 that are never going to upgrade, or people building new systems with
 UFS1 because they are space constrained (for whatever reasons that
 we're not going to debate here: they are still real).


In the past 5 years, I have worked on some embedded systems where UFS1 was
chosen because of very low memory and disk space requirements.
So those systems are real and out there.

Just out of curiousity, what is it about newer compilers that cause
the size of boot2 to increase so much?

Could we do some silly things like removing/reducing the use of printf()
to save some more bytes, in order to buy us more time, before having
to rewrite everything? :)

--
Craig
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org


Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Rui Paulo
On Mar 29, 2015, at 13:29, Craig Rodrigues rodr...@freebsd.org wrote:
 
 Just out of curiousity, what is it about newer compilers that cause
 the size of boot2 to increase so much?

Code generation is different, especially with regards to optimisations.  Longer 
code might be faster because the compiler decided to inline a few functions.  
Unfortunately, I never saw any difference between -Os and -O2 in all of my 
tests (boot2 and other code).

--
Rui Paulo



___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org


Re: Fails to build sys/i386/boot2 with gcc 4.9

2015-03-29 Thread Warner Losh

 On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote:
 
 If we built a UFS1-only boot2, that would fit in the 7.5k we have left
 to play with. We could then build a UFS2-only boot2 that would easily
 fit in the like 32k limit that UFS2 has.
 
 The only reason we went to supporting both was to have something
 universal. Since it requires a reformat to go from UFS1 - UFS2 we
 wanted the transition to be as smooth as possible so you didn’t have
 to add boot blocks into the mix.
 
 Now the only people that use UFS1 are people with really old systems
 that are never going to upgrade, or people building new systems with
 UFS1 because they are space constrained (for whatever reasons that
 we’re not going to debate here: they are still real).
 
 In the past 5 years, I have worked on some embedded systems where UFS1 was 
 chosen because of very low memory and disk space requirements.
 So those systems are real and out there.
 
 Just out of curiousity, what is it about newer compilers that cause
 the size of boot2 to increase so much?
 
 Could we do some silly things like removing/reducing the use of printf()
 to save some more bytes, in order to buy us more time, before having
 to rewrite everything? :)

Removing printf isn’t going to save us. It usually compiles to 80-120 bytes.

I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe
some safety belts in the boot block splatter programs to prevent
brickification.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail


Fails to build sys/i386/boot2 with gcc 4.9

2015-03-28 Thread Craig Rodrigues
Hi,

To work around the problems build rescue, this time I used a build host
running FreeBSD-CURRENT at svn revision r280353

I took this patch for libc++ and applied it to my tree:

http://reviews.llvm.org/D8461

I used this script to build with gcc 4.9:

https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh

Buildling sys/i386/boot2 failed:

=== sys/boot/i386/boot2 (all)
objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=512 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.34 secs (14989607 bytes/sec)
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-fomit-frame-pointer  -mrtd  -mregparm=3  -DUSE_XREAD  -DUFS1_AND_UFS2
-DFLAGS=0x80  -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600
-I/opt2/branches/head/sys/boot/i386/boot2/../../common
-I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I.  -Wall
-Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wwrite-strings  -Winline -march=i386 -ffreestanding
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32
-std=gnu99-Os  -fno-guess-branch-probability  -fno-unit-at-a-time
--param max-inline-insns-single=100 -mpreferred-stack-boundary=2  -S -o
boot2.s.tmp /opt2/branches/head/sys/boot/i386/boot2/boot2.c
/opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'parse':
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:484:6: warning: suggest
parentheses around assignment used as truth value [-Wparentheses]
  if (k = ep - arg) {
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'load':
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:334:9: warning: called from
here [-Winline]
 if (xfsread(ino, hdr, sizeof(hdr)))
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:341:6: warning: called from
here [-Winline]
  if (xfsread(ino, p, hdr.ex.a_text))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:344:6: warning: called from
here [-Winline]
  if (xfsread(ino, p, hdr.ex.a_data))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:349:10: warning: called
from here [-Winline]
  if (xfsread(ino, ep + j, sizeof(ep[0])))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:357:10: warning: called
from here [-Winline]
  if (xfsread(ino, p, ep[i].p_filesz))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:365:10: warning: called
from here [-Winline]
  if (xfsread(ino, es, sizeof(es)))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:371:7: warning: called from
here [-Winline]
   if (xfsread(ino, p, es[i].sh_size))
   ^
sed -e '/align/d' -e '/nop/d'  boot2.s.tmp  boot2.s
rm -f boot2.s.tmp
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-m32 -c boot2.s
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-fomit-frame-pointer  -mrtd  -mregparm=3  -DUSE_XREAD  -DUFS1_AND_UFS2
-DFLAGS=0x80  -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600