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.
