Tracking Issue for llvm-tools-preview

[ehuss]

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

• Ship more LLVM tools with the Rust toolchain #49584 Original issue
• ship LLVM tools with the toolchain #50336 Added tools
• rename the llvm-tools component to llvm-tools-preview and tweak its image #51922 Renamed to -preview
• Provide llvm-strip in llvm-tools component #51962 Added llvm-strip
• add llvm-readobj to llvm-tools-preview #53740 Added llvm-readobj
• Include llvm-ar with llvm-tools component #59351 Added llvm-ar
• Move the target libLLVM to llvm-tools-preview #72000 Moved libLLVM.so around
• Include llvm-dis, llc and opt in llvm-tools-preview component #77868 Added llvm-dis, llc, opt
• Ship llvm-cov through llvm-tools #78947 Added llvm-cov
• Include llvm-as in llvm-tools-preview component #78968 Added llvm-as

[lf-]

Related issue: #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.

[hellow554]

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?

[lf-]

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.

[hellow554]

What about global_asm! together with include_str!? 🤔

[tv42]

These seem to be now available as "llvm-tools" (no "-preview"). Did this issue get accidentally left behind?

[ehuss]

It was inadvertent that the component without the -preview suffix was allowed. This is currently tracked in #119164.

[ehuss]

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 rust-lang/rustup#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.