Export LLVM init functions from rustc_llvm

[nagisa]

Previously these functions would’ve been not exposed in the dynamic libraries for some targets, despite them being regular LLVM API and having no reason to be hidden.

cc @alexcrichton

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

Err, r? @alexcrichton

Brain, work please.

[alexcrichton]

Out of curiosity, why do we want to actively export APIs? Seems like we would prefer the opposite, actively hiding them.

[nagisa]

@alexcrichton my primary motivation for this PR is llvm_build_utils crate. For its purposes librustc_llvm.so is already a pretty good libLLVM.so (as it exposes all of the LLVM’s symbols on many platforms anyway). The problem is that without this patch, MSVC version of the dll does not export symbols to the initialization routines, essentially making the library useless there.

---

I do not want to demand people to install system-wide LLVM or, even worse, build my own, because it is supposed to be just a lean utility for build.rs scripts where we already know there must be a LLVM somewhere (used by rustc).

As far as stability goes, I’m very aware about all potential stability concerns – even the LLVM’s own C API is not stable and try to warn my users about unstability of the crate. Nobody would be able to complain even if librustc_llvm went away.

[alexcrichton]

This seems... like exactly what we don't want librustc_llvm.so to be used for? In the past we've tried supporting things like the executing engine and that just ended in sadness. Our LLVM is intended to be used by rustc and only rustc, and ideally we wouldn't expose any LLVM symbols and would internalize everything.

cc @brson

[brson]

On its own merits, I think the patch makes sense.

But from past experience I think we should actively discourage people from using our LLVM. Constantly-breaking APIs that people depend on are a nightmare.

That said, I recognize that Rust puts great effort into making LLVM work and it would be nice if people writing compilers in Rust could benefit from that.

The linked llvm_build_utils project worries me. With either in-tree or out-of-tree LLVM it will not have any stability guarantees. As written it looks oriented toward producing asm, not LLVM IR to be linked in with Rust's LLVM IR, but I'm still alarmed.

Any attempt to use an out-of-tree LLVM to interop with Rust is in for a lot of pain because of bitcode drift. Any attempt to use an in-tree LLVM for interop with Rust is in for a lot of pain because of API drift. It could be even worse than the serde situation.

[nagisa]

This seems... like exactly what we don't want librustc_llvm.so to be used for?

Aww, that seems like a waste of space. On the other hand, when I put the goggles of a rustc dev, I fully understand and somewhat support this stance. Perhaps it would be a good idea to only ship a librustc_everything.so (with only the stuff necessary for rustc and rustdoc binaries exposed) instead of a shared library for each internal crate?

With either in-tree or out-of-tree LLVM it will not have any stability guarantees.

That’s true. LLVM-IR format or LLVM instruction format may change slightly between LLVM versions (see this, for example), thus potentially making LLVM-IR supplied by to the crate incompatible with new LLVM versions. There’s nothing new about that.

As written it looks oriented toward producing asm, not LLVM IR to be linked in with Rust's LLVM IR, but I'm still alarmed.

As written, it takes LLVM-IR and produces an .a containing machine code, similar to how the gcc crate takes C code and produces an .a. containing machine code. In its spirit itsllc` in a library form. It doesn’t matter what Rust does at all, or what version of LLVM it uses.

Any attempt to use an out-of-tree LLVM to interop with Rust is in for a lot of pain because of bitcode drift. Any attempt to use an in-tree LLVM for interop with Rust is in for a lot of pain because of API drift.

Both IR-format and API drift apply equally to both out-of-tree and in-tree LLVM, provided only the LLVM* (but not LLVMRust) symbols are used.

[alexcrichton]

Seems that our goal would indeed one day be exposing a shared library that has 0 exposed LLVM symbols, so perhaps we don't want to take this route of actively exporting new symbols from LLVM for now?

[nagisa]

Yeah, close this for me if you could. I'll submit some ideas about how to
change distribution later on the forums.

On Jul 31, 2016 10:20, "Alex Crichton" notifications@github.com wrote:

Seems that our goal would indeed one day be exposing a shared library that
has 0 exposed LLVM symbols, so perhaps we don't want to take this route of
actively exporting new symbols from LLVM for now?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#35113 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AApc0tfHKsgW4spDQZ7Op0OwdtxdScpfks5qbEzEgaJpZM4JYVaD
.