re: README: gcc 7 switch coming to a port near you!
matthew green writes: > Andreas Gustafsson writes: > > Some days ago, matthew green wrote: > > > hopefully the sparc testbed will fix itself now. > > > > It did, but MIPS is suffering from what looks like the same issue > > yeah - i commited the hack for it already, but i think i've just > found all the real fixes -- upstream's version of joerg's patch > to gcc/varasm.c plus additional fixes. > > with this, crtbegin.o has a read-only .eh_frame, and libstdc++ > builds sanely. > > i'll be running some local tests before reverting any crunchgen > changes, so hold off any ramdisk etc size bumps for now. OK, i believe all these problems are resolved, as is the problem wiz reported about mpd. i'll probably switch the 32 bit arm ports soon. that will leave: hppa (untested, builds), ia64 and powerpc64 (both have build issues so aren't testable), m68k (maybe ready?), sh3 (builds, not heavily tested), and vax (has a probelm with dynamic binaryes, but static and /rescue work), of the ports that currently build. riscv is also up and coming toolchain and userland. .mrg.
re: README: gcc 7 switch coming to a port near you!
Andreas Gustafsson writes: > Some days ago, matthew green wrote: > > hopefully the sparc testbed will fix itself now. > > It did, but MIPS is suffering from what looks like the same issue yeah - i commited the hack for it already, but i think i've just found all the real fixes -- upstream's version of joerg's patch to gcc/varasm.c plus additional fixes. with this, crtbegin.o has a read-only .eh_frame, and libstdc++ builds sanely. i'll be running some local tests before reverting any crunchgen changes, so hold off any ramdisk etc size bumps for now. thanks. .mrg.
re: README: gcc 7 switch coming to a port near you!
Some days ago, matthew green wrote:
> hopefully the sparc testbed will fix itself now.
It did, but MIPS is suffering from what looks like the same issue
("panic: init died" when booting the install media). This is
affecting the hpcmips and pmax testbeds:
http://releng.netbsd.org/b5reports/hpcmips/2019/2019.02.13.09.57.46/install.log
http://releng.netbsd.org/b5reports/pmax/2019/2019.02.13.17.17.02/install.log
At least on hpcmips, this clearly started with the commit of
bsd.own.mk 1.1102 on 2019.02.08.09.35.00:
lyta /bracket/hpcmips/results $ zgrep -c 'init died' */*/install.log.gz |
tail -12
2019/2019.02.03.03.28.04/install.log.gz:0
2019/2019.02.03.15.43.57/install.log.gz:0
2019/2019.02.06.09.17.18/install.log.gz:0
2019/2019.02.06.11.05.30/install.log.gz:0
2019/2019.02.08.09.17.12/install.log.gz:0
2019/2019.02.08.09.35.00/install.log.gz:1
2019/2019.02.10.19.30.28/install.log.gz:1
2019/2019.02.10.22.36.27/install.log.gz:1
2019/2019.02.11.11.12.58/install.log.gz:1
2019/2019.02.12.06.00.05/install.log.gz:1
2019/2019.02.12.18.32.15/install.log.gz:1
2019/2019.02.13.09.57.46/install.log.gz:1
--
Andreas Gustafsson, g...@gson.org
Re: README: gcc 7 switch coming to a port near you!
Thank you On Tue, Feb 12, 2019 at 2:25 AM matthew green wrote: > > the sparc installer (and likely sparc64 installer) issue should be > hacked around in -current, by not removing .eh_frame as previously > posted. we can fix it properly later when we know why. > > hopefully the sparc testbed will fix itself now. > > > the sparc smp problem i have tracked down (and it is not a gcc 7 > specific issue) and i don't yet understand what is going, but i > have a very simple workaround for it as well. > > the problem happens in the new npf module. i saw this change in > my lists fairly often and ignored it, but i finally managed to > convince myself via bisect it was the problem. > > as a guess, i hacked npf_modctl() to return ENOTTY instead of > calling npf_init(). this allowed my kernel to function fine. > i then noticed npf_init() is static and only called once from > npf_modctl(), and for some reason i tried compiling it with the > static removed. this works. i've confirmed this result a few > times because it is so surprising. > > as a test, i inlind the contents directly and the same problem > occurs, so i suspect what ever is wrong happens when inlined. > > i'm still trying to understand the full asm for either version > but i haven't yet figurd out what is wrong here. > > this is very confusing, and if a compiler bug, is not a new one. > > > .mrg.
re: README: gcc 7 switch coming to a port near you!
matthew green wrote: > the sparc installer (and likely sparc64 installer) issue should be > hacked around in -current, by not removing .eh_frame as previously > posted. we can fix it properly later when we know why. > > hopefully the sparc testbed will fix itself now. I can confirm that the sparc installation now succeeds on my own testbed. Thanks. -- Andreas Gustafsson, g...@gson.org
re: README: gcc 7 switch coming to a port near you!
the sparc installer (and likely sparc64 installer) issue should be hacked around in -current, by not removing .eh_frame as previously posted. we can fix it properly later when we know why. hopefully the sparc testbed will fix itself now. the sparc smp problem i have tracked down (and it is not a gcc 7 specific issue) and i don't yet understand what is going, but i have a very simple workaround for it as well. the problem happens in the new npf module. i saw this change in my lists fairly often and ignored it, but i finally managed to convince myself via bisect it was the problem. as a guess, i hacked npf_modctl() to return ENOTTY instead of calling npf_init(). this allowed my kernel to function fine. i then noticed npf_init() is static and only called once from npf_modctl(), and for some reason i tried compiling it with the static removed. this works. i've confirmed this result a few times because it is so surprising. as a test, i inlind the contents directly and the same problem occurs, so i suspect what ever is wrong happens when inlined. i'm still trying to understand the full asm for either version but i haven't yet figurd out what is wrong here. this is very confusing, and if a compiler bug, is not a new one. .mrg.
re: README: gcc 7 switch coming to a port near you!
for some reason, the .eh_frame section is linked to the crunched
cp binary in ways i don't really understand. i've written this
hack patch that also should help the sparc64 issue until we figure
out a better/real solution to this.
i haven't tested the installer, but rescue works again, and
i didn't test sparc64 either.
.mrg.
Index: crunchgen.c
===
RCS file: /cvsroot/src/usr.bin/crunch/crunchgen/crunchgen.c,v
retrieving revision 1.89
diff -p -u -u -r1.89 crunchgen.c
--- crunchgen.c 26 Jul 2018 08:57:32 - 1.89
+++ crunchgen.c 12 Feb 2019 05:51:09 -
@@ -961,6 +961,15 @@ top_makefile_rules(FILE *outmk)
fprintf(outmk, "LDSTATIC=-static%s\n\n", pie ? " -pie" : "");
fprintf(outmk, "PROG=%s\n\n", execfname);
+
+fprintf(outmk, "OBJCOPY_REMOVE_FLAGS=-R .eh_frame_hdr -R .note -R
.note.netbsd.pax -R .ident -R .comment -R .copyright\n\n");
+
+fprintf(outmk, ".if ${MACHINE} != \"sparc\"\n");
+fprintf(outmk, "OBJCOPY_REMOVE_FLAGS+=-R .eh_frame\n");
+fprintf(outmk, ".endif\n");
+fprintf(outmk, ".if ${MACHINE} != \"sparc64\"\n");
+fprintf(outmk, "OBJCOPY_REMOVE_FLAGS+=-R .note.netbsd.mcmodel\n");
+fprintf(outmk, ".endif\n\n");
fprintf(outmk, "all: ${PROG}.crunched\n");
fprintf(outmk, "${PROG}.crunched: ${SUBMAKE_TARGETS} .WAIT
${PROG}.strip\n");
@@ -969,7 +978,7 @@ top_makefile_rules(FILE *outmk)
fprintf(outmk, "\t@[ -f ${PROG}.unstripped -a ! ${PROG} -nt
${PROG}.unstripped ] || { \\\n");
fprintf(outmk, "\t\t${_MKSHMSG:Uecho} \" strip \" ${PROG}; \\\n");
fprintf(outmk, "\t\tcp ${PROG} ${PROG}.unstripped && \\\n");
-fprintf(outmk, "\t\t${OBJCOPY} -S -R .eh_frame -R .eh_frame_hdr -R .note
-R .note.netbsd.mcmodel -R .note.netbsd.pax -R .ident -R .comment -R .copyright
${PROG} && \\\n");
+fprintf(outmk, "\t\t${OBJCOPY} -S ${OBJCOPY_REMOVE_FLAGS} ${PROG} &&
\\\n");
fprintf(outmk, "\t\ttouch ${PROG}.unstripped; \\\n");
fprintf(outmk, "\t}\n");
fprintf(outmk, "objs: $(SUBMAKE_TARGETS)\n");
re: README: gcc 7 switch coming to a port near you!
> /rescue binaries fail with GCC 7, which is why the qemu runs > are failing -- the installer crashes the same. > > it is not static binaries, but something specific to the > crunchgen'd binaries i guess. > > if i can't figure out the crunchgen problem i'll revert the > switch on sparc but others may want to skip SMP kernels on > sparc for now (and i *just* fixed it! argh.) i'm not very familiar with how this all work, but i have found that it may be a strip or objcopy bug. the "rescue.unstripped" in the rescue objdir runs fine. the program headers are broken in the installed binary. this: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x0001 0x0001 0x66b0f2 0x66b0f2 R E 0x1 LOAD 0x66c000 0x0068c000 0x0068c000 0x75cd0 0x323240 RW 0x1 NOTE 0xb4 0x000100b4 0x000100b4 0x0002c 0x0002c R 0x4 TLS0x6ced08 0x006eed08 0x006eed08 0x0 0x4 R 0x4 becomes Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x0001 0x67b0d6 0x67b0d6 R E 0x1 LOAD 0x67ed08 0x006eed08 0x006eed08 0x12fc8 0x2c0538 RW 0x1 LOAD 0x69ed08 0x006eed08 0x006eed08 0x00040 0x00040 RW 0x1 NOTE 0x0100b4 0x000100b4 0x000100b4 0x00018 0x00018 R 0x4 TLS0x67ed08 0x006eed08 0x006eed08 0x0 0x4 R 0x4 the first problem is virtaddr 0x0. this is (default) disallowed (mapping user VA 0), though enabling it causes a later failure. it's something in the objcopy that makes the "stripped" copy. .mrg.
re: README: gcc 7 switch coming to a port near you!
OK, there are two problems with sparc. one seems to be GCC 7 and one appears to be ... something in mid-late january i am still tracking down. /rescue binaries fail with GCC 7, which is why the qemu runs are failing -- the installer crashes the same. it is not static binaries, but something specific to the crunchgen'd binaries i guess. if i can't figure out the crunchgen problem i'll revert the switch on sparc but others may want to skip SMP kernels on sparc for now (and i *just* fixed it! argh.) .mrg.
re: README: gcc 7 switch coming to a port near you!
matthew green writes: > Andreas Gustafsson writes: > > The sparc testbed is panicing with "init died" when booting the INSTALL > > kernel since the gcc 7 switch. Logs at: > > = > > > http://releng.netbsd.org/b5reports/sparc/2019/2019.02.08.19.45.24/inst= > all.log > > actually, i'm fairly sure this is _not_ gcc 7. i can repeat > this failure with gcc 6 or gcc 7, and it appeared sometime > after january 19 -- i had my ss20 booting gcc 7 from that > era tree, but when i updated to sometime after the module > compat branch merge (not that i'm blaming it!) it started > to hang again on me. > > thanks for reminding me about it. > > can someone have a look? even run some bisect? i'm still > busy with other gcc 7 related issues... i did a couple of quick tests, and i may be wrong about this not being gcc 7. unfortunately, i'm having slow build issues. stay tuned for more. .mrg.
re: README: gcc 7 switch coming to a port near you!
Andreas Gustafsson writes: > The sparc testbed is panicing with "init died" when booting the INSTALL > kernel since the gcc 7 switch. Logs at: > > > http://releng.netbsd.org/b5reports/sparc/2019/2019.02.08.19.45.24/install.log actually, i'm fairly sure this is _not_ gcc 7. i can repeat this failure with gcc 6 or gcc 7, and it appeared sometime after january 19 -- i had my ss20 booting gcc 7 from that era tree, but when i updated to sometime after the module compat branch merge (not that i'm blaming it!) it started to hang again on me. thanks for reminding me about it. can someone have a look? even run some bisect? i'm still busy with other gcc 7 related issues... thanks. .mrg.
Re: README: gcc 7 switch coming to a port near you!
The sparc testbed is panicing with "init died" when booting the INSTALL kernel since the gcc 7 switch. Logs at: http://releng.netbsd.org/b5reports/sparc/2019/2019.02.08.19.45.24/install.log -- Andreas Gustafsson, g...@gson.org
re: README: gcc 7 switch coming to a port near you!
Andreas Gustafsson writes: > matthew green wrote: > > i plan to switch amd64 and arm64 to GCC 7 soon. > > The number of ATF test failures on real amd64 hardware jumped > from 0 (+ occasional random failures) to 44: > > > http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2019/2019.02.08.13.37.46/test.html#failed-tcs-summary with latest sources i've reduced this to the 3 FP ones and 4 of the others that are still failing for me all related to c++ call_once stuff: t_call_once:call_once_pic_profile, t_call_once:call_once_pic_profile_32, t_call_once2:call_once2_32, t_call_once2:call_once2_static
re: README: gcc 7 switch coming to a port near you!
Andreas Gustafsson writes: > matthew green wrote: > > i plan to switch amd64 and arm64 to GCC 7 soon. > > The number of ATF test failures on real amd64 hardware jumped > from 0 (+ occasional random failures) to 44: > > > http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2019/2019.02.08.13.37.46/test.html#failed-tcs-summary there seem to be two classes problems here: a couple fp related failures, and a bunch of sanitizer failures. the first i'm not sure about. the second is because i broken libasan recently and it has missing symbols.. fixing. .mrg.
Re: README: gcc 7 switch coming to a port near you!
matthew green wrote: > i plan to switch amd64 and arm64 to GCC 7 soon. The number of ATF test failures on real amd64 hardware jumped from 0 (+ occasional random failures) to 44: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2019/2019.02.08.13.37.46/test.html#failed-tcs-summary -- Andreas Gustafsson, g...@gson.org
re: README: gcc 7 switch coming to a port near you!
the build problem for pkg_install should be fixed now. .mrg.
Re: README: gcc 7 switch coming to a port near you!
On Thu, Feb 07, 2019 at 11:10:30AM -0600, John D. Baker wrote:
> [...]
> --- cleandir-external ---
> --- cleandir-lib ---
> cleandir ===> external/bsd/pkg_install/lib
> [...]
> --- cleandir-external ---
> nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line
> 16: Malformed conditional (defined(HAVE_GCC) && ${HAVE_GCC} == 7 &&
> ${ACTIVE_CC} == "gcc")
> [...]
Try the attached version.
Joerg
Index: Makefile.inc
===
RCS file: /cvsroot/src/external/bsd/pkg_install/Makefile.inc,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile.inc
--- Makefile.inc5 Feb 2019 11:37:18 - 1.5
+++ Makefile.inc7 Feb 2019 22:15:06 -
@@ -13,7 +13,7 @@ WARNS=4
CWARNFLAGS+= -Wno-missing-noreturn
# show_version() does not return
-.if defined(HAVE_GCC) && ${HAVE_GCC} == 7 && ${ACTIVE_CC} == "gcc"
-COPTS.main.c+= -Wno-error=implicit-fallthrough
-COPTS.pkg_delete.c+= -Wno-error=implicit-fallthrough
+.if ${HAVE_GCC:U0} == 7
+COPTS.main.c+= ${${ACTIVE_CC} == "gcc" :?
-Wno-error=implicit-fallthrough :}
+COPTS.pkg_delete.c+= ${${ACTIVE_CC} == "gcc" :?
-Wno-error=implicit-fallthrough :}
.endif
Re: README: gcc 7 switch coming to a port near you!
On Thu, 7 Feb 2019, Anders Lindgren wrote:
> A quick test suggest this will happen if ${ACTIVE_CC} simply isn't defined
> when the expression is evaluated, effectively yielding:
>
> defined(7) && 7 == 7 && == "gcc"
That makes sense. Since this is a "cleandir" operation, there is no
ACTIVE_CC (I should think), so the variable is undefined or empty.
Perhaps ACTIVE_CC needs a 'defined()' test as well, or at least wrap in
double-quotes for a valid string comparison.
Just did this now (wrap ${ACTIVE_CC} in double-quotes: "${ACTIVE_CC}")
in the reported failing Makefile.inc and started the build over. The
clean-dir for "...pkg_install/lib" appears to have succeeded. The build
(target=sparc) is proceeding.
Although I see numerous Makefile* files with this same idiom, perhaps
it was just this one "Makefile.inc" that was affected due to the
conditional being evaluated outside of a target where ACTIVE_CC would
otherwise be guaranteed to be defined?
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: README: gcc 7 switch coming to a port near you!
On Thu, 7 Feb 2019, John D. Baker wrote:
On Thu, 07 Feb 2019 22:27:58 +1100, matthew green
wrote:
if you'd like to test now from -current, build a clean tree
with build.sh -V HAVE_GCC=7. it should just work..
How clean is "clean tree"? I'm simply performing a non-update build
into objdir last populated by a previous update build (w/o HAVE_GCC=7).
I'm getting the following failure (amd64-8.0_STABLE host):
[...]
--- cleandir-external ---
--- cleandir-lib ---
cleandir ===> external/bsd/pkg_install/lib
[...]
--- cleandir-external ---
nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line 16: Malformed conditional
(defined(HAVE_GCC) && ${HAVE_GCC} == 7 && ${ACTIVE_CC} == "gcc")
[...]
FWIW, I hade the same problem (amd64 host, amiga target) with a completely
new and empty objdir and sources as of this morning, CET.
A quick test suggest this will happen if ${ACTIVE_CC} simply isn't defined
when the expression is evaluated, effectively yielding:
defined(7) && 7 == 7 && == "gcc"
/ali
Re: README: gcc 7 switch coming to a port near you!
On Thu, 07 Feb 2019 22:27:58 +1100, matthew green
wrote:
> if you'd like to test now from -current, build a clean tree
> with build.sh -V HAVE_GCC=7. it should just work..
How clean is "clean tree"? I'm simply performing a non-update build
into objdir last populated by a previous update build (w/o HAVE_GCC=7).
I'm getting the following failure (amd64-8.0_STABLE host):
[...]
--- cleandir-external ---
--- cleandir-lib ---
cleandir ===> external/bsd/pkg_install/lib
[...]
--- cleandir-external ---
nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line
16: Malformed conditional (defined(HAVE_GCC) && ${HAVE_GCC} == 7 &&
${ACTIVE_CC} == "gcc")
[...]
I see a number of Makefile* files with this idiom, but this is the only
one it's tripping on (so far). I don't see what it thinks is malformed
about it. Manually nuking the affected objdir sub-tree doesn't affect
the result.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
