Re: lang/gcc fails on -current

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.