-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error from wrong header parsing when compiling CentOS kernel #47
Comments
I have searched high and low for this "race". Usually restarting the build works. I have no idea what is going on. I used the go tool for race detection. No luck. (i.e no races) Searched through the code. Gave up in the end. It was very very annoying. |
Restarting the build really usually worked, but I run into totally new thing, i get this error every time i start a new build (even after calling
Whole error log with the same error ran with
As it is not just one letter and .h file extension. Whole log: error_elper.log As you said, it usually only required to start again, but now I get it every few compiler calls. (perhaps it could be clang issue?) Would you give me some pointers to gllvm source code and how the parsing works please? I really want to help with this issue. Edit: Another interesting thing, clang doesn't know option |
Excellent. Thank you @DanielKriz! I will give you a tour later today. |
Lets concentrate on The parsing is done on line 63 of The parser's job is to:
Note that there is no concurrency yet. Once we have parsed the cmds into a This is where the concurrency occurs, assuming we have to produce bitcode. The parser is long but pretty straightforward, it tries to do exact matches first, then I am pretty sure, but you should check, that once created the ParserResult object pr is not mutated. So really not a lot of room for parallel weirdness. |
Note that you could pretty easily instrument the code to dump each pr object out to the log.
say by adding this to line 64 of compiler.go. |
By the way, do you mean that
All errors disappear, or just one particular type of error? |
Just this particular error, but after some times (kernel compilation is very long) it again threw that error, but much much later. Unfortunately no matter how many times I restarted the build, the error prevailed. |
Any progress on this mystery @DanielKriz? |
My main suspect is clang, because I have two system fedora 34 with clang 12 and Ubuntu 18,04 with clang 11. On Fedora the bug happens very often and even restarting the build doesn't help. On the ubuntu on the other hand, the build progresses with 0-2 occurences. I am preparing some containers to try the build with different versions of clang and I am also trying to understand gllvm codebase and Golang (as I started learning it just because of this bug, it's pretty neat language. I must say) I will update you as I get all the logs from the containers. |
Interesting. One possibility is that the two almost identical concurrent calls to clang somehow manage to interfere |
When building CentOS kernel (v. 4.18..0-193.el8) with gllvm, sometimes there is some non-existent header (usually consisting from one letter and .h file extension, for example
r.h
). I suspect that this could be because of some bug in parsing.This kernel and it's config is acquired using rhel-kernel-get
Enviroment
Example of error
from
Intereting thing is, that there is no header ending with
r.h
. Just to be sure I checked all preceding gclang calls and there is none such header either.How to reproduce
This error usually happened when using multiple threads/core to compile linux kernel (-j option), it is almost guaranteed to happen at some point during compilation.
Rarely it happens when no number of cores is specified, this way it usually only once per compilation.
When called with
make -j1 CC=gclang
(because for example ninja build system needs to be called with -j1 to use just one core), it seems to be almost guaranteed to occur.Is there a way how to fix this?
The text was updated successfully, but these errors were encountered: