Solved clang error during kernel compilation

TempleBSD

Member

Reaction score: 14
Messages: 43

Hello,

I have just upgraded my system from 12.2-Release to 13.0-Release without any problems. I had a custom kernel set up before and wanted to compile one for the upgraded install too. Obtained relevant /usr/src from git with branch releng/13.0 and configured it using a copy of GENERIC. I then started the build but shortly an error similar to this one popped up:
Code:
1.    ./pci_if.h:101:2: current parser token 'return'
2.    ./pci_if.h:96:1: parsing function body 'PCI_GET_VPD_IDENT'
3.    ./pci_if.h:96:1: in compound statement ('{}')
#0 0x0000000003b24fae (/usr/bin/cc+0x3b24fae)
#1 0x0000000003b23355 (/usr/bin/cc+0x3b23355)
#2 0x0000000003ac9061 (/usr/bin/cc+0x3ac9061)
#3 0x0000000806e73e00 (/lib/libthr.so.3+0x19e00)
cc: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 11.0.1 ([email]git@github.com[/email]:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd13.0
Thread model: posix Installed
Dir: /usr/bin cc: note: diagnostic msg:
I fiddled around but with every config I tried (even bog standard GENERIC) i get the same type of error but different file/state. This made me try with aslr and stackgap disabled for both /usr/bin/clang and /usr/bin/clang++ and while that fixes the error, the compilation then just fails on random errors (i.e. "unterminated conditional directive" and so on) in random files.

- compiling from/for x86_64
- unmodified source tree
- freshly upgraded system

If anything else is needed, please do not refrain from asking.
Thank you for your time
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

the compilation then just fails on random errors
You might want to check your system for memory errors. I've had similar weird, seemingly random, build issues and it turned out to be some bad memory. Building world is quite a test for your system, it's a really good stress-test for the whole machine.
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

That sounds reasonable, thanks. I'll give memtest a go and try swapping out some sticks. Weird why that would show after an upgrade though. My 12.2 compilation wasn't that long ago. I'll report back after I've had the time. Thanks again.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

My 12.2 compilation wasn't that long ago.
You may not have had the memory issue back then. Or it didn't push the machine as hard as the compilation of 13.0 does. In any case, just test the memory, even if it's only to rule it out as a possible cause.
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

Doesn't seem like memory is an issue. I'm at one successful pass of memtest86 (though I intend to let it run through three) without any errors.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

I'm at one successful pass of memtest86 (though I intend to let it run through three) without any errors.
One pass will usually do, if there's anything really wrong it would have shown up by now. At least we ruled it out as a possible cause (it took me a long time to realize my memory was bad).

So, we're going to hunt for other potential issues. Do you have anything in /etc/make.conf and/or /etc/src.conf? Perhaps /etc/src-env.conf?
 

covacat

Aspiring Daemon

Reaction score: 333
Messages: 681

if it bombs in various ways it is very probably hardware
if you can reproduce it any number of times it's probably not the hardware
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

if it bombs in various ways it is very probably hardware
One thing that might be a problem, TempleBSD are you doing any overclocking on the machine? That could lead to instabilities too.
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

So, we're going to hunt for other potential issues. Do you have anything in /etc/make.conf and/or /etc/src.conf? Perhaps /etc/src-env.conf?
/etc/src.conf and /etc/src-env.conf both do not exist and /etc/make.conf contains only the two lines placed in there by installing linuxulator. trying with make.conf removed caused the same error.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

/etc/src.conf and /etc/src-env.conf both do not exist
Ok, that's good, then they can't interfere either.
/etc/make.conf contains only the two lines placed in there by installing linuxulator.
Installing it shouldn't change anything in that file.
trying with make.conf removed caused the same error.
Ok, that's good. Well, it's good that it's out of the way. It's not so good because it still doesn't work.

So, lets circle back to the beginning.
Obtained relevant /usr/src from git with branch releng/13.0
How? Did you use git(1) or gitup(8)? Or used some other way of getting the source?

I then started the build
How did you start the build? cd /usr/src and make buildworld?
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

How? Did you use git(1) or gitup(8)? Or used some other way of getting the source?
I initially obtained it with doas git clone -b releng/13.0 --depth 1 https://git.freebsd.org/src.git /usr/src but then to remove git as a variable tried doas svn checkout https://svn.freebsd.org/base/head /usr/src while I'm not too sure of the second one. Either way, both produced the same error.
How did you start the build? cd /usr/src and make buildworld?
cd /usr/src and then doas make buildkernel kernconf=CUSTOM after having placed my config in /usr/src/sys/amd64/conf/CUSTOM

Do you know of any good CPU stresstests I could try to check? Running benchmarks/unixbench now.

UPDATE: Unixbench crashed by sigabort quite quickly after which I tweaked some settings in the BIOS (which will be listed if they work) and now unixbench got past the point of the last crash which gives me a little hope. Gonna let it run through and try a compilation afterwards.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

while I'm not too sure of the second one
The sources for 13.0 aren't on SVN anymore, the head there is an old 13-CURRENT. Only the 11.x and 12.x versions are still maintained in SVN. Use git(1) to get the sources for 13.0 or higher.

cd /usr/src and then doas make buildkernel kernconf=CUSTOM after having placed my config in /usr/src/sys/amd64/conf/CUSTOM
Build world fist. Or run make kernel-toolchain first. And the proper way to set the kernel to build is KERNCONF=CUSTOM
Code:
     kernel-toolchain      Rebuild the tools needed for kernel compilation.
                           Use this if you did not do a buildworld first.
Code:
     KERNCONF             Overrides which kernel to build and install for the
                          various kernel make targets.  It defaults to
                          GENERIC.
build(7)
 

diizzy

Aspiring Daemon

Reaction score: 193
Messages: 577

If you see random crashes you should also consider that you have corrupted files (and binaries) so you probably want do a fresh install once you've verified that your hardware is stable.
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

The sources for 13.0 aren't on SVN anymore, the head there is an old 13-CURRENT. Only the 11.x and 12.x versions are still maintained in SVN. Use git(1) to get the sources for 13.0 or higher.
Reverted back to git now.
Build world fist. Or run make kernel-toolchain first. And the proper way to set the kernel to build is KERNCONF=CUSTOM
Thanks for pointing that out. The fully qualified monkey I am is definitely incapable of reading manpages.
If you see random crashes you should also consider that you have corrupted files (and binaries) so you probably want do a fresh install once you've verified that your hardware is stable.
Trying to avoid that really. Some time investment is involved with that and I'd love to avoid re-doing my setup. Thanks for the suggestion.

Unixbench now completed.
I'm remapping clang10 to clang12 (in /etc/make.conf) to see if that changes anything because I still got a crash during toolchain build. No idea if that's reasonable though.
Have you got any idea whether aslr/stackgap can interfere with the kernel compilation? Building world succeeded under 12.2 with both of them on so it should not be an issue right? I will reboot with these turned off and try again after the currently running attempt. I'm also using devel/ccache but to avoid conflicts did clear out the whole cache between changes.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,764
Messages: 39,365

I'm remapping clang10 to clang12 (in /etc/make.conf) to see if that changes anything because I still got a crash during toolchain build. No idea if that's reasonable though.
Have you got any idea whether aslr/stackgap can interfere with the kernel compilation? Building world succeeded under 12.2 with both of them on so it should not be an issue right? I will reboot with these turned off and try again after the currently running attempt. I'm also using devel/ccache but to avoid conflicts did clear out the whole cache between changes.
To rule out any issues build it as "plain" as possible. No messing around with compilers, ASLR or any other advanced features. Disable ccache too. Building a bog standard world should always work. Once that builds properly you can try enabling certain features or using ccache.
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

Disabled all entries in /etc/sysctl.conf (followed by a reboot) set by me, ran a pkg check -sa to check for corrupted binaries and then started the compilation with make buildworld from plain userland. Issue still persists. Checked git stash to check whether any files had changed locally. This is very confusing to me. Looks like its gonna be a reinstall once I find the time to do that. I will try and compile from a live-usb to see if that changes something.
 

diizzy

Aspiring Daemon

Reaction score: 193
Messages: 577

For now pkg will only check ports and not base unless you used pkgbase I guess
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

I'm compiling from a live-usb chrooted into my current systems drive and its been going alright so far. At least it has lasted for an hour now which is far longer than my install took until crashing. I don't yet understand which component would be faulty if the live-compile works as chrooting would make me use all packages/files from my main system leaving only the kernel and modules loaded during boot as variables correct? This assumption should be verifiable after the compilation succeeded by then trying to build world again with the new kernel booted. Thanks you two for sticking with me so far!
 

Tieks

Well-Known Member

Reaction score: 128
Messages: 307

TempleBSD said:
I don't yet understand which component would be faulty

Did you rule out file system problems after upgrading to v13?
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

Did you rule out file system problems after upgrading to v13?
Not specifically, no. I only checked whether enough space was available and it sure is. How would you go about finding problems with the filesystem?

Compiling the kernel chrooted through live-usb worked. Now booted into the newly compiled one and recompiling it to see whether some issue with my kernel caused the instability.
 
OP
T

TempleBSD

Member

Reaction score: 14
Messages: 43

Thanks guys, somewhat solved. Compiled new kernel from chroot into my systems drive from the live session of the installer stick. The newly compiled kernel fixed the issue and I can now successfully build world on my machine. Weird.
 
Top