-current 'make release' status?
Hi,
I'm currently down to this patch to allow a make release to complete
for -current:
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.801
diff -u -r1.801 Makefile
--- Makefile26 Jul 2003 06:47:40 - 1.801
+++ Makefile29 Jul 2003 05:09:31 -
@@ -1053,7 +1053,7 @@
cd ${.CURDIR}/..; \
KERNEL_KO=BOOTMFS KODIR= \
${CROSSMAKE} ${KERNEL_FLAGS} -DNO_MODULES -DNO_KERNELCLEAN \
- KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -DNO_CPU_COPTFLAGS \
+ KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -w -DNO_CPU_COPTFLAGS \
buildkernel reinstallkernel \
DESTDIR=${RD}/kernels
[ -r ${.CURDIR}/../sys/${TARGET}/conf/BOOTMFS.hints ] \
without it, the following causes BOOTMFS to abort:
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys
-I/usr/src/sys/dev -I/usr/src
/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
-I/usr/src/sys/contrib/dev/a
th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000
-mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c
In file included from /usr/src/sys/cam/cam_periph.c:41:
/usr/src/sys/sys/buf.h: In function `BUF_LOCK':
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
/usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will
break strict-aliasing rules
.
.
.
Thoughts? Plans?
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
initial build via 'make release' fails with no patch. After the failure,
a followup:
chroot $RDIR /bin/sh
/mk doMFSKERN
works correctly. The 'make release' environment is setup differently
from that of /mk. Depending on what folks think, maybe some form of:
make mk TARGET=doMFSKERN
would be appropriate to guarentee consistancy. Just a thought.
-John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status?
On Tue, Jul 29, 2003 at 06:30:54AM -0400, John wrote:
Hi,
I'm currently down to this patch to allow a make release to complete
for -current:
[...]
Try setting the KERNEL_FLAGS=-DNO_WERROR instead.
without it, the following causes BOOTMFS to abort:
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I.
-I/usr/src/sys -I/usr/src/sys/dev -I/usr/src
/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
-I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/a
th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000
-mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c
In file included from /usr/src/sys/cam/cam_periph.c:41:
/usr/src/sys/sys/buf.h: In function `BUF_LOCK':
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
/usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will
break strict-aliasing rules
.
.
.
Thoughts? Plans?
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
initial build via 'make release' fails with no patch. After the failure,
a followup:
chroot $RDIR /bin/sh
/mk doMFSKERN
works correctly. The 'make release' environment is setup differently
from that of /mk. Depending on what folks think, maybe some form of:
make mk TARGET=doMFSKERN
would be appropriate to guarentee consistancy. Just a thought.
If this is the case, then it's a bug and should be fixed. I am
looking to see now if I can reproduce the problem, but a wild
guess is that: release/Makefile calls chroot(8) a bit differently,
with a clean environment, like this:
env -i /usr/sbin/chroot ${CHROOTDIR} /mk
Could it be that you have something in your environment similar
to NO_WERROR?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: -current 'make release' status? [SOLVED]
On Tue, Jul 29, 2003 at 09:41:54AM -0400, John De Boskey wrote: - Ruslan Ermilov's Original Message - No, I have nothing in my environment that should affect the build, no /etc/make.conf in the chroot area.. But then again: running make rerelease is effectively just calls the command above. I'm currently in the middle of the make release and will see if this is reproduceable. # chroot /vol/vol0/work/5-current-chrootdir /bin/sh # env A few things not needed that are inherited from my normal account, but nothing that should have a negative affect. Do you still get the error if you try make rerelease? Do you still get the error if you try chroot ... /mk? Do you still get the error if you try env -i chroot ... /mk? I'll see what I can find.. John, I see the same breakage as you do. But in all three cases above, I see the same breakage (as expected). Even if I'm running chroot /data/ru/R then ./mk doMFSKERN, I still get it: : In file included from /usr/src/sys/cam/cam_periph.c:41: : /usr/src/sys/sys/buf.h: In function `BUF_LOCK': : /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break strict-aliasing rules : ... : *** Error code 1 : : Stop in /usr/obj/usr/src/sys/BOOTMFS. Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
In the last episode (Jul 29), Ruslan Ermilov said: Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. That does work, but there are still things you can't turn off with -f. They're half-aliases. toplev.c::parse_options_and_default_flags does set -f flags based on the optimization level, but there is still a whole lot of gcc code that directly tests the value of optimize and optimize_size. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter ^^ This was too complete :-). I meant -Wno-strict-aliasing when I wrote it (since I misread the info about -Os). than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Yes, this seems to be the only option that needs warnings about strict aliasing. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
