-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
gollvm: build fails in combination with -fcf-protection=branch #38728
Comments
Hi, in theory the issue tracker is not for questions or support requests (just Go bugs), but this could be a bug in the makefiles I guess? So leaving open for investigation cc @thanm @cherrymui |
As mentioned previously, this sort of question is better off sent to the go-nuts mailing list, as opposed creating an issue. Looking at your cmake output, it seems likely that there is some issue with the C compiler you are using. What happens when you do this:
Does this succeed for you? |
@thanm Yes, it succeeds.
Edit: I accidentally submitted the wrong cc version before. The real version is 9.3.0. The script succeeds. |
Update: with help of @sitilge , who ran some experiments on the build system, it was eventually determined that the system GCC is hard-wiring on the "-fcf-protection=branch" option (or equivalent). This results in function prologs that can't be recognized by ld.gold. Typical function prolog without -cf-protection=branch:
and prolog with -cf-protection=branch:
The additional 'endbr64' is confusing gold's pattern match. Next step is to file an upstream issue for the ld.gold problem. Will hold this issue open until I have more info. |
Sent upstream binutils bug here. |
Does it mean that this issue should be closed? |
@hdost not yet, I still have a couple of CLs to submit. Should be able to close it out in a day or two. |
Change https://golang.org/cl/232740 mentions this issue: |
Change https://golang.org/cl/232738 mentions this issue: |
Change https://golang.org/cl/232497 mentions this issue: |
Change https://golang.org/cl/232739 mentions this issue: |
Change https://golang.org/cl/232742 mentions this issue: |
Thanks again for submitting this bug. I've checked in a series of CLs that should address all of the problems-- things should build cleanly again now at tip for LLVM and gollvm. |
@thanm No problem, that was the least I could do. Thank you for help! |
I still get the same error using the latest commit in |
OK, I will reopen this bug and take another look-- perhaps I missed something the first time around. |
I am still unable to reproduce this latest failure. When I test at tip using a compiler that hard-wires on -fcf-protection=branch I get a clean build. For anyone still encountering this problem, please rerun your cmake command and look for the following in the trace output:
If you don't see this, please post what you are seeing from cmake. It would also help to know which specific commit you're picking up in the gollvm repo (e.g. "git log -1 --oneline"). Thanks. |
I find those lines intertwined. I paste the whole output of
Commit: |
You wrote:
That's the LLVM commit hash. I'm interested in the Gollvm hash, e.g.
It should be at 2ded6bd. Thanks. |
Absolutely. I'm sorry for that. Yes: |
Thanks. Would it be possible to share the last couple of pages of the CMakeFiles/CMakeOutput.log file? Maybe that might given an indication as to why the cmake run is failing (since I don't see any red flags in the transcript you posted). |
Sure. I directly attach both log files: |
Well, I am stumped at the moment. The log files you posted are functionally identical to the ones from one of my recent builds, but your run seems to fail and mine does not. About all I can suggest at this point is cleaning our your build area (rm -r CMakeFiles CMakeCache.txt) and starting from a clean slate, since I can't find anything actionable in your logs at all. |
I had already tried to clean my build, that does not fix the issue. Just in case you are interested on following this, the only think that comes to my mind for reproduction is to build the same environment. The issues raises on a fresh ubuntu 20.04 docker container. Other than the base stuff I only recall to have installed |
If you can post detailed instructions for creating the container (etc) I can give that a try; I do have access to a macbook. |
Sure. I attach a Dockerfile.txt Then I can reproduce just following these steps:
|
Change https://golang.org/cl/240637 mentions this issue: |
Change https://golang.org/cl/240560 mentions this issue: |
Change https://golang.org/cl/240558 mentions this issue: |
Change https://golang.org/cl/240559 mentions this issue: |
I've sent in a couple of CLs that should address the build issues, and @erifan also sent a fix. Things should be buildable using your Docker container now. Note that you'll need to include m4 in the dependences, and insure that SHELL env is set. Let me know if you have additional problems. |
Yeah. Thanks. Just in case other face the same issue, I do not know exactly why but I have some issues with the compilation now but I guess this issue is already fixed. |
Does this issue reproduce with the latest release?
Yes (with latest commit to master).
What operating system and processor architecture are you using (
go env
)?Ubuntu Focal Fossa, amd64
What did you do?
I followed the instructions on the gollvm landing page.
What did you expect to see?
The project builds cleanly.
What did you see instead?
I got this output
The output of CMakeError.log is around 2.5k lines. Here is a snippet:
Has anyone managed to build gollvm? Or have a Docker image? The Docker images publicly available are somewhat old and also gave me bugs.
The text was updated successfully, but these errors were encountered: