On 22/07/2019 14:06, Stuart Henderson wrote: > On 2019/07/22 13:36, Nigel Taylor wrote: >> On 22/07/2019 12:21, Stuart Henderson wrote: >>> On 2019/07/22 08:36, Pavel Korovin wrote: >>>> On 07/20, Nigel Taylor wrote: >>>>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but >>>>> there are more afterwards. Too many errors to fix by hand. >>>>> >>>>> The problem I think lies in opening files for writing when they don't >>>>> exist, it fails to create an empty file. So I manually touch sinfo.h to >>>>> create the empty file. Same for other missing files. >>>>> >>>>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada >>>>> >>>>> >>>>> Not sure where the error is could be with the ada bootstrap file, needs >>>>> regenerating. >>>> >>>> The same problem here, please find the diff for gcc8 attached. >>> >>> Yet the Makefiles are presumably OK on other systems, and are OK on i386. >>> >>> Has anyone figured out what triggered this to start failing and what is >>> actually going on? >>> >>> Wondering if there's an LP64 related problem. The only other 64-bit arch >>> building ada support in ports/lang/gcc/8 is mips64. Anyone know if that >>> still works? >>> >>> The most obvious candidate to my eyes would be realpath, if there's some >>> problem with this it could impact many many ports. So I think we should >>> figure out what's really going on before committing workarounds to gcc >>> which take the whole thing off the radar. >>> >>> >> >> This is a ktrace/kdump side by side of grep CALL's one with and one >> without sinfo.h present. >> >> 70692 xsinfo CALL write(1,0x444b5f5cc1f,0x1) >> │ >> 76912 xsinfo CALL write(1,0x97722da4c1f,0x1) >> 70692 xsinfo CALL write(1,0x7f7ffffd8580,0x35) >> │ >> 76912 xsinfo CALL write(1,0x7f7ffffa5ce0,0x35) >> 70692 xsinfo CALL __realpath(0x7f7ffffee630,0x7f7ffffeddf0) >> │ >> 76912 xsinfo CALL __realpath(0x7f7ffffbbd90,0x7f7ffffbb550) >> 70692 xsinfo CALL >> open(0x7f7ffffee630,0x601<O_WRONLY|O_CREAT|O_TRUNC>,0666<S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH>) >> │ 76912 xsinfo CALL kbind(0x7f7ffffbb8a0,24,0x494ab4884a3e974f) >> 70692 xsinfo CALL fstat(4,0x7f7ffffee150) >> │ >> 76912 xsinfo CALL kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f) >> 70692 xsinfo CALL __realpath(0x7f7ffffee630,0x7f7ffffeddf0) >> │ >> 76912 xsinfo CALL kbind(0x7f7ffffbb7f0,24,0x494ab4884a3e974f) >> 70692 xsinfo CALL open(0x7f7ffffee630,0<O_RDONLY>) >> │ >> 76912 xsinfo CALL >> mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) >> 70692 xsinfo CALL fstat(5,0x7f7ffffee150) >> │ >> 76912 xsinfo CALL >> mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) >> >> Only when the file exists after the __realpath call is open called, >> suggesting __realpath is returning an error for the missing file, >> causing the open to be skipped. Could be realpath returning wrong error >> in this case or runtime looking for the wrong error or not expecting an >> error. >> >> As a quick check I reverted back to a kernel I built 15 July, with that >> kernel xsinfo works when sinfo.h is missing. >> >> >> Which looks, this change might be the cause of problems. but only >> guessing. But doesn't seem to tie up with your later email. >> >> cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c >> Index: vfs_syscalls.c >> =================================================================== >> RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v >> retrieving revision 1.321 >> retrieving revision 1.323 >> diff -u -p -r1.321 -r1.323 >> --- vfs_syscalls.c 12 Jul 2019 13:56:27 -0000 1.321 >> +++ vfs_syscalls.c 15 Jul 2019 15:05:21 -0000 1.323 >> @@ -1,4 +1,4 @@ >> -/* $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp >> $ */ >> +/* $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */ >> /* $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $ >> */ >> >> /* >> @@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v, >> NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH, >> UIO_SYSSPACE, pathname, p); >> else >> - NDINIT(&nd, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT | >> SAVENAME | >> + NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT | >> SAVENAME | >> REALPATH, UIO_SYSSPACE, pathname, p); >> >> nd.ni_cnd.cn_rpbuf = rpbuf; >> >> >> I'll look at building kernel with this reverted. Not saying the change >> isn't right, but may have exposed error checking which is wrong. >> > > Hmm. Well based on the ktrace it's likely that this will avoid the problem. > *ponders* > > We've already seen different codepaths taken in other ports (augeas) due to > autoconf detecting realpath differently. > > ENOTIME right now but maybe worth trying to build a new adastrap after having > applied pvk's patch, then switch to the new adastrap, pull the patch out > again, > and see if it can then build without it. > > > Little chance of that working, but only my view, and I don't know how to build a new adastrap. Having built gnat and using the installed gnat to build xsinfo and run which still fails, and the fact reverting to old kernel make the same work. It's either revert the kernel or some fix in the ada libraries. Just I'm only guessing where to start looking.
I updated from cvs /usr/src/sys, rebuilt kernel and installed under / Then reverted vfs_syscalls.c rebuilt kernel and install under / booted kernel, and check xsinfo with missing file failed as expected. booted reverted kernel check xsinfo with missing file, was successful. That gives a possible temporary fix. Now to look for how ada libraries / Create works
