rust
rust copied to clipboard
rust-lang
Tracking Issue for llvm-tools-preview
This is a tracking issue for the llvm-tools-preview.
llvm-tools-preview is a rustup component that contains some LLVM tools. At the time of this writing, it contains the following:
- llc
- llvm-ar
- llvm-as
- llvm-cov
- llvm-dis
- llvm-nm
- llvm-objcopy
- llvm-objdump
- llvm-profdata
- llvm-readobj
- llvm-size
- llvm-strip
- opt
Steps
- [ ] Write some documentation (not sure where this should live)
Unresolved Questions
- What will it take to transition out of
-preview?
Implementation history
- #49584 Original issue
- #50336 Added tools
- #51922 Renamed to
-preview - #51962 Added llvm-strip
- #53740 Added llvm-readobj
- #59351 Added llvm-ar
- #72000 Moved libLLVM.so around
- #77868 Added llvm-dis, llc, opt
- #78947 Added llvm-cov
- #78968 Added llvm-as
Related issue: https://github.com/rust-lang/rust/issues/56371
The use case that I want clang for is the integrated assembler, for assembling .s files in my rust kernel build process. I don't believe that there's currently any way of invoking the llvm based assembler except through the clang driver.
The use case that I want clang for is the integrated assembler, for assembling .s files in my rust kernel build process.
If you are using a nightly compiler you could use the asm! macro?
The use case that I want clang for is the integrated assembler, for assembling .s files in my rust kernel build process.
If you are using a nightly compiler you could use the
asm!macro?
Not really, if you are a kernel. Generally you want your init code and similarly large pieces of assembly outside of rust files, since you want to create jump tables and such that don't belong to a function, among other things. It's rather hacky to try to do everything with inline assembly.
These seem to be now available as "llvm-tools" (no "-preview"). Did this issue get accidentally left behind?
It was inadvertent that the component without the -preview suffix was allowed. This is currently tracked in #119164.
There was a discussion at https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/llvm-tools.20stabilization about the accidental removal of the -preview suffix.
I think to summarize: People agree that we should not remove the llvm-tools component and break users currently using it. However, it doesn't seem like there is consensus it should be treated as stable. I have posted https://github.com/rust-lang/rustup/pull/3707 to add a comment about the status.
I had some uncertainty about who is actually responsible for this component. I think by default it should probably be the compiler team delegating to wg-llvm if needed.
There is some uncertainty about the directory where the tools currently reside. Currently they are in the target directory, but they are host tools so they should probably be located somewhere else. There should also probably be a rustc --print option for locating that directory. (I assume it should not be in $SYSROOT/bin, since that seems like it could really break things if people have that in their PATH.)
I'll also copy @wesleywiser's last comment, which seemed like a good summary:
I agree that simply saying "llvm-tools may break at any time" is uncomfortable, but I think the fairest statement is that "llvm-tools are provided as-is from upstream LLVM". In most cases, they aren't going to break all the time or even occasionally. At the same time, we're not going to take on maintaining a tool LLVM has dropped just to fulfil a stability promise. I think the vast majority of users would totally understand this position and not have an issue with that.
This feels very similar to the Target Tier Policy where we do not promise perpetual support for any particular target, just a level of support in a given release. Breakage in upstream LLVM has even necessitated demoting targets from Tier 2 to Tier 3 because they're simply too broken to be at that level.