Skip to content
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

llvm: factor out compiler-rt, fix libstdcxxStdenv sanitizer headers #39743

Merged
merged 4 commits into from
May 24, 2018

Conversation

Ralith
Copy link
Contributor

@Ralith Ralith commented Apr 30, 2018

Motivation for this change

This fixes the libcxxStdenv build of projects that use e.g. the AddressSanitizer API to improve error detection when using custom allocators, and improves factoring.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@dtzWill
Copy link
Member

dtzWill commented Apr 30, 2018

LGTM.

It's unfortunate that no one knows why we built this as part of LLVM in the first place. Did something need it? xD.

But a variety of very basic testing shows things working as they should, on both glibc and musl.

Do none of the other components need or benefit from compiler-rt?

Also, might be worth doing the same for LLVM5 and seeing what the Darwin builders think of the change-- to exercise clang-based stdenv's and get ahead of possible problems when eventually moving to LLVM6 as default.

Does this sound reasonable, @NixOS/darwin-maintainers ? Have some build cycles to spare? :)

@dtzWill
Copy link
Member

dtzWill commented Apr 30, 2018

Would it be much work to put together a little test for the behavior this fixes, and add it as a cc-wrapper test or something? So we can (try to) avoid regressing on it.

Just a thought :).

@Ralith
Copy link
Contributor Author

Ralith commented Apr 30, 2018

It's unfortunate that no one knows why we built this as part of LLVM in the first place. Did something need it? xD.

IIRC we hunted down the party responsible (@shlevy?) in IRC and they were reasonably confident that it was just a workaround for historical brokenness in the LLVM build system--its degree of support for compiling components separately has varied in the past.

Would it be much work to put together a little test for the behavior this fixes, and add it as a cc-wrapper test or something? So we can (try to) avoid regressing on it.

Such a test should be simple, especially if you can point me to an example cc-wrapper test to model it on, as I haven't written a NixOS test before. Is there any danger of planting a land mine for support of compilers that don't implement the usual sanitizers, though? I imagine e.g. icc might be an issue.

@Ralith
Copy link
Contributor Author

Ralith commented Apr 30, 2018

Factoring compiler-rt out of LLVM doesn't have to happen simultaneously with fixing the bug in the clang package, but they're both going to touch clang so it's probably worth getting the rebuilds out of the way in one go.

@dtzWill
Copy link
Member

dtzWill commented Apr 30, 2018

We have various cc-wrapper tests that are specifically for clang -- various versions, using libc++ and libstdc++. I think perhaps they could go there? https://github.com/NixOS/nixpkgs/tree/master/pkgs/test/cc-wrapper

Anyway this can happen in a follow-up and as time allows :).

@shlevy
Copy link
Member

shlevy commented May 1, 2018

Yes, I definitely wanted to compile this separately from the get-go but it didn't work way back when I added it.

@dtzWill
Copy link
Member

dtzWill commented May 1, 2018

Yes, I definitely wanted to compile this separately from the get-go but it didn't work way back when I added it.

Oh, well that settles that! I didn't mean to place blame in any way--often details of a decision are lost over time :). Anyway thanks for clearing that up!

@dtzWill
Copy link
Member

dtzWill commented May 9, 2018

Basic testing suggests this is fine but I'm a bit too swamped to more thoroughly review/test. Don't block on my account, sorry!

@Ralith
Copy link
Contributor Author

Ralith commented May 18, 2018

Is this blocked?

@matthewbauer
Copy link
Member

Can you rebase to staging? Otherwise looks good. The build farm is a little busy right now but I can merge after that clears up.

@matthewbauer matthewbauer reopened this May 18, 2018
@Ralith Ralith changed the base branch from master to staging May 18, 2018 21:01
@Ericson2314
Copy link
Member

Ericson2314 commented May 18, 2018

Woah!!! Very very very excited this exists.

@GrahamcOfBorg GrahamcOfBorg added 6.topic: GNOME GNOME desktop environment and its underlying platform 6.topic: golang 6.topic: haskell 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS labels May 18, 2018
@peti peti removed their request for review May 22, 2018 08:29
inherit version;
src = fetch "compiler-rt" "16m7rvh3w6vq10iwkjrr1nn293djld3xm62l5zasisaprx117k6h";

nativeBuildInputs = [ cmake python llvm ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure LLVM is just a build tool here? So it is a nativeBuildInput.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reallllyyy??? No wonder you were asking about using a stand-in for llvm-config, wonder what the details here are.

@Ericson2314
Copy link
Member

OK I did the merge. This should be good now.

@GrahamcOfBorg GrahamcOfBorg removed the 2.status: merge conflict This PR has merge conflicts with the target branch label May 22, 2018
Copy link
Member

@dtzWill dtzWill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM, haven't tested extensively but don't expect much to break.

TYVM for moving the musl patching over 👍.

inherit version;
src = fetch "compiler-rt" "16m7rvh3w6vq10iwkjrr1nn293djld3xm62l5zasisaprx117k6h";

nativeBuildInputs = [ cmake python llvm ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reallllyyy??? No wonder you were asking about using a stand-in for llvm-config, wonder what the details here are.

@@ -51,13 +53,17 @@ let
outputs = [ "out" "lib" "python" ];

# Clang expects to find LLVMgold in its own prefix
# Clang expects to find sanitizer libraries in its own prefix
# Clang expects to find sanitizer libraries and headers in its own prefix
postInstall = ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyone have details about this?

Also discussed elsewhere in this PR (#39743 (comment)) -- I'd just like to know about the issues, as it'd be awfully nice to not have to link these bits over... (perhaps combined with a wrapper or so).

Copy link
Contributor Author

@Ralith Ralith May 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll see if it's possible to get away with -L and -isystem for these. The approach taken here was based on the existing code and the expectations of the clang developers, but it isn't necessarily impossible to do otherwise. If it works out, how would I go about injecting them gracefully?

e: Wait, now I think I get what @Ericson2314 was suggesting. Will experiment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good! If it's a big deal, we can look into it later--don't mean to push all of our LLVM-related TODO's onto your PR! 😁

But if you don't mind taking a look that'd be great! Thanks!

@ttuegel ttuegel removed their request for review May 22, 2018 23:19
@dtzWill
Copy link
Member

dtzWill commented May 23, 2018

FWIW initial musl testing looks good! Woo! 👍

@Ericson2314
Copy link
Member

OK rebased on some careful cherry-picks so there's no conflicts. If we can make clang not depend on compiler-rt, then we can build compiler-rt with the newly-built clang, which will be good (nearly sufficient!) for cross compilation.

@Ericson2314
Copy link
Member

Also the separate "tools" and "libraries" part of obsidiansystems@acf2ed5 would be nice to have. I might try to incorperate that.

@Ralith
Copy link
Contributor Author

Ralith commented May 23, 2018

Contrary to my initial reaction, depsTargetTarget does, in fact, seem to be adequate for compiler-rt!

@GrahamcOfBorg GrahamcOfBorg added the 6.topic: stdenv Standard environment label May 23, 2018
@Ericson2314 Ericson2314 force-pushed the compiler-rt branch 2 times, most recently from 64106b4 to d9458a9 Compare May 24, 2018 06:41
@GrahamcOfBorg GrahamcOfBorg removed the 6.topic: stdenv Standard environment label May 24, 2018
@Ericson2314
Copy link
Member

Only the wrapper script knows about compiler-rt, and both tests pass!

@Ericson2314 Ericson2314 merged commit 11d26c7 into NixOS:staging May 24, 2018
@Ralith Ralith deleted the compiler-rt branch May 24, 2018 20:16
Ericson2314 added a commit that referenced this pull request May 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants