C This C preprocessor brokenness is driving me nuatz! Looking for ideas.

cracauer@

cracauer@

Developer
One of several 16-current machines doesn't build kernel or world, on identical /usr/src trees. The others work fine as always. The problem seems to be rooted at the macro SYSCTL_PROC(...) from FreeBSD base expanding to nothing.

Code: 
[...] -o spa.o
/xcarb3/usr/src/sys/contrib/openzfs/module/zfs/spa.c:11341:1: error: too few arguments provided to function-like macro invocation
 11341 | ZFS_MODULE_VIRTUAL_PARAM_CALL(zfs_zio, zio_, taskq_free,
       | ^
/xcarb3/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/mod_os.h:54:39: note: expanded from macro 'ZFS_MODULE_VIRTUAL_PARAM_CALL'
   54 | #define ZFS_MODULE_VIRTUAL_PARAM_CALL ZFS_MODULE_PARAM_CALL
      |                                       ^
/xcarb3/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/mod_os.h:51:2: note: expanded from macro 'ZFS_MODULE_PARAM_CALL'
   51 |         ZFS_MODULE_PARAM_CALL_IMPL(_vfs_ ## scope_prefix, name, perm, \
      |         ^
/xcarb3/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/mod_os.h:47:75: note: expanded from macro 'ZFS_MODULE_PARAM_CALL_IMPL'
   47 |     SYSCTL_PROC(parent, OID_AUTO, name, CTLFLAG_MPSAFE | perm | args, desc)
      |                                                                           ^
/xcarb3/usr/src/sys/sys/sysctl.h:816:9: note: macro 'SYSCTL_PROC' defined here
  816 | #define SYSCTL_PROC(parent, nbr, name, access, ptr, arg, handler, fmt, descr) \
      |         ^
/xcarb3/usr/src/sys/contrib/openzfs/module/zfs/spa.c:11341:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]
 11341 | ZFS_MODULE_VIRTUAL_PARAM_CALL(zfs_zio, zio_, taskq_free,
       | ^
/xcarb3/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/mod_os.h:54:39: note: expanded from macro 'ZFS_MODULE_VIRTUAL_PARAM_CALL'
   54 | #define ZFS_MODULE_VIRTUAL_PARAM_CALL ZFS_MODULE_PARAM_CALL
      |                                       ^
/xcarb3/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/mod_os.h:51:2: note: expanded from macro 'ZFS_MODULE_PARAM_CALL'
   51 |         ZFS_MODULE_PARAM_CALL_IMPL(_vfs_ ## scope_prefix, name, perm, \
      |         ^
/xcarb3/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/mod_os.h:47:5: note: expanded from macro 'ZFS_MODULE_PARAM_CALL_IMPL'
   47 |     SYSCTL_PROC(parent, OID_AUTO, name, CTLFLAG_MPSAFE | perm | args, desc)
      |     ^
2 errors generated.
*** Error code 1

Obviously there should be a problem in the C compiler install or in /usr/include.

Here is what I tried:
- plaster a snapshot over / - no change
- rsync /usr/include from a working machine - no change
- empty /etc/make.conf and copy a make.conf from a working machine - no change
- `diff -y` a complete truss of a compiler run for spa.o - no obvious causes
- remove obsolete files via Makefile in /usr/src - no change but broke PAM. That was "fun"
- use `cc -E` to compare output of cpp - nothing obvious

I then went and did `sh release.sh` in /usr/src/release, which builds world and kernel. Worked fine. Install the result to / - still broken. WTF?

Any further ideas for try-n-error are welcome.
 
sounds like you've borked the compiler in a way that produces a borked compiler. was there a make clean or equivalent involved at any point?
 
atax1a said:
sounds like you've borked the compiler in a way that produces a borked compiler. was there a make clean or equivalent involved at any point?
Click to expand...

Yes, about 100 of them. And plastering a snapshot over / would break such a bad compiler chain. Still puzzled.
 
Use ktrace -di / kdump to see what files are being accessed & compare with what happens on machine where it builds. [Also: in general screwing around with make clean, rsync, mount etc. will simply confuse you further!]
 
bakul said:
Use ktrace -di / kdump to see what files are being accessed & compare with what happens on machine where it builds. [Also: in general screwing around with make clean, rsync, mount etc. will simply confuse you further!]
Click to expand...

Yeah, you're right. I have truss runs of both working and non-working machines. On first sight nothing sprung to mind, but I should dig deeper into them.
 
Zare said:
Well, are you sure the machine works? Is it a VM or a machine whose RAM can go faulty?
Click to expand...

The problem is 100% reproducible. It' always the same macros.

In addition `make world` worked when I ran it from /usr/src/release (it uses a chroot and a fresh environment). To clarify, on the same machine. Once I install the result to / it has the same problem again.

Keep 'em coming, really appreciate hard questions.
 
cracauer@ said:
The problem is 100% reproducible. It' always the same macros.

In addition `make world` worked when I ran it from /usr/src/release (it uses a chroot and a fresh environment). To clarify, on the same machine. Once I install the result to / it has the same problem again.

Keep 'em coming, really appreciate hard questions.
Click to expand...
Well, if I understand your comment then that means it is an environment problem, and not a compiler bug. Not sure what is meant by "install the result to /". Do you mean move the build environment back outside of the chroot, or the result of the build?

I'm not up on BSD best-practices but isn't /usr/src/release where it is SUPPOSE to be built?
 
kent_dorfman766 said:
Well, if I understand your comment then that means it is an environment problem, and not a compiler bug. Not sure what is meant by "install the result to /". Do you mean move the build environment back outside of the chroot, or the result of the build?

I'm not up on BSD best-practices but isn't /usr/src/release where it is SUPPOSE to be built?
Click to expand...

"Install the results to /" means I untarred the tarfiles that /usr/src/release built. Everything base system except /etc

Normally you don't have to go /usr/src/release to recompile your world as `make world` in /usr/src also cleans the environment. Just not enough in this case :) Also, /usr/src/release doesn't support local changes to src.
 
cracauer@ said:
In addition `make world` worked when I ran it from /usr/src/release (it uses a chroot and a fresh environment). To clarify, on the same machine. Once I install the result to / it has the same problem again.
Click to expand...
This seems like you are not picking up the installed binary. In my script I explicitly set PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
 
bakul said:
This seems like you are not picking up the installed binary. In my script I explicitly set PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
Click to expand...

I tried a build from a user account with no dotfiles. I don't think it is environment variables.
 
atax1a said:
also, what's different about that one machine from the others? does it have ECC RAM? are you building on ZFS or UFS?
Click to expand...

One is an AMD CPU laptop. The other is an Intel Desktop (the b0rked one). Both amd64. No ECC on either. The broken one has src and obj on ZFS. Everything else on that machine and the whole working AMD is on UFS.


I am crusading down the VM route now. I am using a working VM and will transfer more and more of the broken install until it breaks. With snapshots in between for binary search.

In parallel I will have a second look at the truss output comparison.
 
is it one of those Intels where the CPU eventually kills itself because the adaptive mechanism overvolts the CPU over time?
 
You must log in or register to reply here.
Back
Top