search

rust-lang / rustc_codegen_gcc

libgccjit AOT codegen for rustc
Apache License 2.0
916 stars 60 forks source link

Plans for cross compilation (?) #15

Open avdgrinten opened 3 years ago

avdgrinten commented 3 years ago

To the best of my knowledge, libgccjit can currently only target the current CPU architecture, while rustc is a natural cross compiler. Are there any plans to reconcile that, for example by dynamically loading libgccjit.so for the right target? (I am not sure if it is even possible to build such a libgccjit.so right now.)

For many GCC-supported platforms such as AVR, it would be crucial to get cross-compilation support working.

antoyo commented 3 years ago

I haven't tested it yet, but it should be possible to build libgccjit.so for the target architecture to allow cross-compiling.

avdgrinten commented 3 years ago

I haven't tested it yet, but it should be possible to build libgccjit.so for the target architecture to allow cross-compiling.

Right. I just tested a aarch64 target on x86_64. ./configure --target also works with libgccjit (this post here seemed to state the opposite but that might just be misinterpreting it: https://gcc.gnu.org/pipermail/jit/2020q3/001251.html)

That still leaves the problem of loading the right .so library according to the rustc target. Luckily, the ABI of libgccjit does not seem to depend on the target, so that should be possible.

antoyo commented 3 years ago

That still leaves the problem of loading the right .so library according to the rustc target. Luckily, the ABI of libgccjit does not seem to depend on the target, so that should be possible.

What are your thoughts on this? Is there any standard paths to library for different architectures on Linux?

avdgrinten commented 3 years ago

GCC's build script usually prefix cross compilers with the target triple, for example aarch64-linux-gcc or aarch64-elf-gcc for a bare metal target. I think it would be natural to search for a triple-prefixed libgccjit.so first, with a fallback to a non-prefix one if the rustc compilation target matches the host OS.

antoyo commented 3 years ago

There are indeed paths like /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0 and /usr/lib/gcc/aarch64-linux-gnu/11.1.0, and libgccjit.so should end up there.

joshtriplett commented 3 years ago

In theory, it should be possible to dlopen the appropriate libgccjit, so that there's one rustc_codegen_gcc backend that works for any supported target. We could then distribute the appropriate compiled versions of libgccjit for each supported Rust target that uses the GCC backend. (The Rust toolchain already requires installing support for each target, so it wouldn't be onerous to include the compiled libgccjit in that target support.)

bjorn3 commented 3 years ago

The Rust toolchain already requires installing support for each target, so it wouldn't be onerous to include the compiled libgccjit in that target support.

Current targets only install libraries for the target and not the host, keeping the amount to down to # targets versions, while libgccjit would need # targets * # hosts versions. This may become a problem as we get more targets or would already be a problem.

joshtriplett commented 3 years ago

@bjorn3 That's true, but it's also an inherent limitation of the GCC model, in which one toolchain has only one target. Given that limitation, either way each host will need one libgccjit for each supported target. So, I think it'd be preferable to not propagate that limitation into rustc_codegen_gcc, and instead have just one copy of rustc_codegen_gcc per host.

(At least, assuming that turns out to be architecturally feasible.)