Targeting an arch in gcc but not in LLVM.

[cr1901]

I'm on vacation till Wednesday, but I figured I should ask this question now while it's fresh on my mind:

I'm interested in getting Rust support as soon as possible for a few architectures with the new gcc codegen; SuperH would be the highest priority for me. What current obstacles exist for me to try out cross compiling to bare-metal sh2/j2, and reporting back (and maybe even fixing, if I can get a grasp on RTL!) any issues I can find. What obstacles exist for attempting to test sh2 codegen using rustc? I can think of a few, but would love to know more:

1. I understand that distributing libgccjit.so is more complicated than the LLVM backend because each libgccjit.so can only target one arch. Has there been movement on how all the different libgccjit.sos should coexist?
   1. I don't remember where, but I heard libgccjit.so is difficult to use in a cross-compile setting; how true is that?
2. I'm not sure if libcore is tested for any arch where libstd doesn't exist in Rust proper, let alone for gcc codegen backends. Is there a way to run the libcore tests in qemu or the gdb simulators? Testing libcore would be a good litmus test for bare-metal sh2/j2¹.
3. Upstream rustc would have to have a target registered for sh2/j2, and would somehow need to know that only the gcc codegen backend is supported for now (LLVM backend might come later, but it's not a high priority). Does this "choose a backend" logic already exist in upstream Rust? Is there additional ABI work that needs to be done to add sh2 upstream?

I assume 2. and 3. need to be handled first before I can start actual codegen for "archs which only have a gcc port". I'd be interested in getting the ball rolling there (at the very least testing, or contributing code depending on how much time I can allocate to this).

Footnotes

1. Right now the common Linux ABI seems to be MMU-less fdpic, and I have no idea whether rustc meaningfully supports anything like it.

[antoyo]

I'm on vacation too.

1. will be under discussion to see what we can do with rustup
2. I guess we could cross-compile the libcore tests and run them in qemu.
3. Not sure I understand. For the first part, you mean in rustup? For the "choose a backend", there's already a command line argument to select the gcc/cranelift codegen, is this what you mean? For the ABI, there might be some work needed in Rust indeed. There will also be work needed for the new inline assembly syntax.

[glaubitz]

I'm one of Debian's porters for the less common architectures such as m68k and sh4 (SuperH).

I can bootstrap rustc for any architecture in Debian once rustc_codegen_gcc has been upstreamed into rustc and the Rust compiler can be switched to use libgccjit rather than libllvm.

I guess we will have to add the various boilerplates for the additional architecture to rustc then once rustc_codegen_gcc has been upstreamed.

[cr1901]

I'm back from vacation.

For the first part, you mean in rustup?

Not necessarily, rustc proper also supports the --target flag.

For the "choose a backend", there's already a command line argument to select the gcc/cranelift codegen, is this what you mean?

What I mean is, something like rustc --target=sh2 by itself should "just work" by defaulting to a libgccjit codegen at a suitable path, and error if the appropriate libgccjit is not installed. Additionally, something like rustc --target=sh2 -Zcodegen-backend=/path/to/libllvm should also error out because there is no libllvm that supports sh2. Though maybe logic like that already exists in libllvm?

@antoyo I guess my overarching question is: What can I do to start adding cross-compilation support to rustc_codegen_gcc, taking the above into account, without getting in your way?

[antoyo]

Sorry for the delay.

As far as I know --target is merely the target triple used and it has no logic to choose a backend. If you would like to change this behaviour (or add a new flag doing what you would like) I suggest you start a discussion somewhere (maybe on Zulip) and ultimately open a MCP to propose the change to the compiler team.

To start helping on the rustc side, you could start a discussion to see whether you can start adding the new architectures you would want in this directory and the new inline-asm register support for those new architectures so that this code can be completed with those new architectures.
Maybe you'll have to wait until the gcc codegen is merged, but this discussion can start now ;) .

[bjorn3]

The target spec used to have a field to specify which backend to use. This was introduced to allow emscripten to use a rustc_codegen_llvm linked against emscripten's llvm instead of the newer default llvm used by rustc. I removed this field in rust-lang/rust#74394 as the emscripten support no longer needed a different llvm and thus the field wasn't used anymore.

[cr1901]

@bjorn3 Are you aware of any difficulties adding backend selection back, in similar to how it was (before it was removed)?

Maybe you'll have to wait until the gcc codegen is merged, but this discussion can start now ;) .

@antoyo Things have changed on my end in the past 4 weeks, so right now I don't have the time I thought I would to commit to starting a backend port (besides testing x86). But I can at least open issues, get feedback, and study your code in the interim :). I just need a few weeks to get things sorted.

[antoyo]

Some notes from my attempts at running Rust code in a Debian m68k qemu virtual machine:

• WIP PR adding notes for cross-compilation: Add notes for cross-compilation to gcc-only targets #68
• The object crate will need to support the new architectures in order to compile dylib.
• The libc crate will need to support the new architectures (it seems to be my last blocker in order to run the tests from libcore on m68k).

I was able to run a simple program using core and a "hello world" using the std on m68k.

[cr1901]

@antoyo Excellent :D! In the coming days, I'll see if I can duplicate this setup in the coming days in rcg_docker, which has bitrotted a bit since your rebase.

[MabezDev]

The object crate will need to support the new architectures in order to compile dylib.
The libc crate will need to support the new architectures (it seems to be my last blocker in order to run the tests from libcore on m68k).

Are these required for no_std builds? I'd like to take a stab at compiling for Xtensa using the GCC backend. Is it possible to statically compile core etc with just specifying TARGET_TRIPLE?

[bjorn3]

Are these required for no_std builds?

The object crate needs to support it the new target. While in the past it was only necessary for dylibs, rustc now also uses object for writing object files containing the crate metadata in rlibs.

Is it possible to statically compile core etc with just specifying TARGET_TRIPLE?

Once you add support to the object crate (and update rustc with the new version) and compile libgccjit to target xtensa (every compiled version of gcc can only target a single triple unlike llvm) it may work.

[antoyo]

@MabezDev Also, if you want to use inline assembly, that will require an update in rustc to support this architecture.

[glaubitz]

@antoyo Do you have a quick guide on how to bootstrap rustc using the backend for a given architecture?

I would love to give it a try with m68k which currently uses the work-in-progress LLVM backend.

[MabezDev]

@MabezDev Also, if you want to use inline assembly, that will require an update in rustc to support this architecture.

Thanks for the hint! Fortunately I've already added Xtensa assembly support in our fork that uses a custom llvm backend: esp-rs/rust@9d4ab85

[antoyo]

@antoyo Do you have a quick guide on how to bootstrap rustc using the backend for a given architecture?

I would love to give it a try with m68k which currently uses the work-in-progress LLVM backend.

That might be simpler to wait until upstream rustc is updated with the latest changes in this repository, but if you want to do it manually locally, here's how to do it.

Add the missing changes from rustc_codegen_gcc in your local rustc repo (might require to use the commit for nightly-2022-03-26).

Update the config.toml in the rustc repo to add the following config:

changelog-seen = 2

[rust]
codegen-backends = ["gcc"]
deny-warnings = false
new-symbol-mangling = true

then, run the following command:

LIBRARY_PATH=/path/to/libgccjit_dir LD_LIBRARY_PATH=/path/to/libgccjit_dir ./x.py install -j4 --stage 1 --host m68k-unknown-linux-gnu --target m68k-unknown-linux-gnu

I haven't tried cross-compiling rustc yet, so that might not work.

[bjorn3]

I haven't tried cross-compiling rustc yet, so that might not work.

It probably won't work. Rustc needs to be compiled for the build machine in addition to the chosen host to build the standard library. This would require some way to choose the right libgccjit for depending on the triple to compile for.

[glaubitz]

Rustc needs to be compiled for the build machine in addition to the chosen host to build the standard library.

Wouldn't it be possible to build a Rust cross-compiler with the standard Rust compiler on the host system?

This would require some way to choose the right libgccjit for depending on the triple to compile for.

On Debian unstable, we should have libgccjit versions for all targets.

[bjorn3]

Wouldn't it be possible to build a Rust cross-compiler with the standard Rust compiler on the host system?

The standard library needs to be compiled by the exact same rustc version as the one that actually uses it. This means that we first have to build stage1 rustc for the host using the bootstrap compiler. This stage1 rustc can then build libstd. And finally another stage1 rustc can be built for the target which can then load the aformentioned libstd version.

[antoyo]

Wouldn't it be possible to build a Rust cross-compiler with the standard Rust compiler on the host system?

The standard library needs to be compiled by the exact same rustc version as the one that actually uses it. This means that we first have to build stage1 rustc for the host using the bootstrap compiler. This stage1 rustc can then build libstd. And finally another stage1 rustc can be built for the target which can then load the aformentioned libstd version.

Do you have any suggestion on how we could do that, perhaps by specifying multiple libgccjit.so paths in the config file?

[bjorn3]

That would be an option.

[glaubitz]

One option might be to build the suitable libgccjit version during the build process of rustc itself similar to what's already done with LLVM.

Would that be feasible?

[antoyo]

@glaubitz Continuing the discussion from #123 here:

m68k support in libc is complete now, but the rustc source tree has not updated to the latest version of libc due to a Illumos-related change breaking the CI (it's being worked on).

One thing you might try is editing the file build_sysroot/sysroot_src/library/std/Cargo.toml (that you get after running prepare.sh) in the repo of rustc_codegen_gcc to use the latest version of libc:

[patch.crates-io]
libc = { git = "https://github.com/rust-lang/libc", default-features = false, features = ['rustc-dep-of-std'] }

That might work.

[glaubitz]

@glaubitz Continuing the discussion from #123 here:

That might work.

I think I can just update the libc crate in my local branch using cargo update -p libc --precise, so that's probably not the biggest issue.

The only thing that I haven't understood yet: From where do I get a libgccjit that can cross-compile for a given architecture? Do I build libgccjit from source for that purpose?

[antoyo]

The only thing that I haven't understood yet: From where do I get a libgccjit that can cross-compile for a given architecture? Do I build libgccjit from source for that purpose?

Yes, you always have to compile it because I have patches that have not been included in any released libgccjit. The readme contains the instructions of how to do so..

By the way, the instructions in the readme are outdated:

• You should no longer have to disable 128-bit integer types.
• You should comment more lines in src/base.rs.

[glaubitz]

OK, thanks a lot! I will give it a try!

[antoyo]

You also won't need this step if rustc now have the m68k target triple:

Since rustc doesn't support this architecture yet, set it back to TARGET_TRIPLE="mips-unknown-linux-gnu" (or another target having the same attributes). Alternatively, create a [target specification file](https://book.avr-rust.com/005.1-the-target-specification-json-file.html) (note that the arch specified in this file must be supported by the rust compiler).

Also, I realized the instructions are not that clear, so you can take a look at this commit to understand what is meant in the instructions.

[antoyo]

I think I can just update the libc crate in my local branch using cargo update -p libc --precise, so that's probably not the biggest issue.

Just in case I wasn't clear, you want to use the latest libc in the program you compile, not within rustc, so you'll have to update the file build_sysroot/sysroot_src/library/std/Cargo.toml like I mentioned earlier.

The reason I couldn't run the tests of libcore on m68k was seemingly because the test runner would run the test executables with a syscall and one was called with an invalid value (since it wasn't using the constants for m68k).

[antoyo]

@glaubitz One more thing, in case you don't know already: use my fork of gcc as some of my patches were not merged yet upstream.

[dkm]

FYI, I've merged the support for libgccjit in crosstool-ng (crosstool-ng/crosstool-ng#1873). This may help in getting the lib for some other target (initial goal was to have a cross rustc_cg_gcc in compiler-explorer compiler-explorer/compiler-explorer#3760)

[benjhar]

Is there any update on this? I'm interested in the SuperH architecture exactly as well, does the opener or anyone else have any information/progress?

[glaubitz]

Is there any update on this? I'm interested in the SuperH architecture exactly as well, does the opener or anyone else have any information/progress?

If you're interested in SuperH, you might want to join #linux-sh on Libera IRC as well as #debian-ports on OFTC IRC.

[glaubitz]

@antoyo Here is a write-up that details how to use rustc_codegen_gcc to target bare-metal SuperH (sh-elf): https://dreamcast.wiki/Rust_on_Dreamcast

This should help us get started to add support for {alpha,hppa,sh4}-unknown-linux-gnu.

If I understood you correctly, you've already got a working compiler for m68k-unknown-linux-gnu? If yes, have all the necessary patches already been upstreamed? And, if yes, can you tell me how to build a native rustc for m68k-unknown-linux-gnu with the help of rustc_codegen_gcc?

[antoyo]

@glaubitz: I have a working cross-compiler targetting m68k-unknown-linux-gnu from x86-64.
You mean the patches to GCC? No, I still have a bunch to merge for gcc 14 (and the one necessary for unwinding will not be merged for gcc 14).

I could try building a native rustc for m68k-unknown-linux-gnu, but it is very likely it won't be able to compile many programs (I haven't tried on x86 for a long time, but back then, that was an issue). Would that still be useful for you?

Did you try to cross-compile other softwares (like librsvg or cargo) for m68k?

[glaubitz]

Some notes from my attempts at running Rust code in a Debian m68k qemu virtual machine:

* WIP PR adding notes for cross-compilation: [Add notes for cross-compilation to gcc-only targets #68](https://github.com/rust-lang/rustc_codegen_gcc/pull/68)

* The `object` crate will need to support the new [architectures](https://github.com/gimli-rs/object/blob/d26bc89508852bfe446e06ba5a22f0066ab9e1f1/src/common.rs#L5) in order to compile dylib.

* The `libc` crate will need to support the new [architectures](https://github.com/rust-lang/libc/tree/master/src/unix/linux_like/linux/arch) (it seems to be my last blocker in order to run the tests from libcore on m68k).

I was able to run a simple program using core and a "hello world" using the std on m68k.

m68k support has been added to libc in rust-lang/libc@7a027d3. Support in object is missing, but I can take care of that, too.

What I still don't understand: How do we make rustc aware of an architecture which is not supported by rustc_codegenllvm? This would be the first step before we can add support for these new architectures to libc as the libc crate can only add targets that rustc recognizes.

[GuillaumeGomez]

Maybe by adding a vec into the target info: supported_by: Vec<Backend> where Backend would be an enum composed of Llvm, Gcc and Cranelift?

[glaubitz]

Maybe by adding a vec into the target info: supported_by: Vec<Backend> where Backend would be an enum composed of Llvm, Gcc and Cranelift?

Sounds plausible to me. Do you have a rough idea how this would look like?

[GuillaumeGomez]

A new field in base that is used for all targets (example here) I suppose?

[dkm]

Have you checked https://rustc-dev-guide.rust-lang.org/building/new-target.html ?

…

On June 29, 2024 1:36:48 PM UTC, Guillaume Gomez ***@***.***> wrote: A new field in `base` that is used for all targets (example [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/aarch64_apple_darwin.rs)) I suppose? -- Reply to this email directly or view it on GitHub: #49 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[glaubitz]

Have you checked https://rustc-dev-guide.rust-lang.org/building/new-target.html ?

I have added rustc_codegen_llvm targets before. But I have no clue how to wire up rustc_codegen_gcc targets.

And, more surprisingly, the instructions to build rustc for the Dreamcast using the sh-elf don't even seem to patch the Rust tree in any way to add support for this target.

I would expect that we would need to add spec files to rustc_target at least.

[darcagn]

Have you checked https://rustc-dev-guide.rust-lang.org/building/new-target.html ?

I have added rustc_codegen_llvm targets before. But I have no clue how to wire up rustc_codegen_gcc targets.

And, more surprisingly, the instructions to build rustc for the Dreamcast using the sh-elf don't even seem to patch the Rust tree in any way to add support for this target.

I would expect that we would need to add spec files to rustc_target at least.

I'm using a little bit of a trick for that in my scripts that wrap the rustc_codegen_gcc tools. rustc thinks it's compiling for MIPS, and so it outputs object files that contain the SH code from GCC but with MIPS architecture specified in the header. The script then rewrites to SH before sending these as input to the linker.

As for the libc crate, I've been able to add support for our homebrew KallistiOS on Dreamcast because I am gating the configuration behind a kallistios OS target in the target JSON file and in forked libc/rust crates and not worrying about architecture-specific configurations. I haven't published these forks yet but I will do so in the coming weeks as time permits.

It has been working fine doing this so far, but obviously this isn't the right way to handle things and we'll need to add SH, etc. to rustc properly in the long run.

[glaubitz]

I'm using a little bit of a trick for that in my scripts that wrap the rustc_codegen_gcc tools. rustc thinks it's compiling for MIPS, and so it outputs object files that contain the SH code from GCC but with MIPS architecture specified in the header. The script then rewrites to SH before sending these as input to the linker.

OK, that clarifies my confusion. Thanks a lot!

As for the libc crate, I've been able to add support for our homebrew KallistiOS on Dreamcast because I am gating the configuration behind a kallistios OS target in the target JSON file and in forked libc/rust crates and not worrying about architecture-specific configurations. I haven't published these forks yet but I will do so in the coming weeks as time permits.

Adding libc is relatively easy if you're just adding a new Linux target (which is what I'm interested in).

It has been working fine doing this so far, but obviously this isn't the right way to handle things and we'll need to add SH, etc. to rustc properly in the long run.

Would be great to document this as well as possible to ease the process of adding new libgccjit targets for others.

[gyrovorbis]

I'm not super familiar with what exactly @darcagn had to go through to get all of this set up with rustc_codegen_gcc targeting SH4, but I have been on the KallistiOS side helping to support the back-end needs for the Rust stdlib and even tokio async library on the Sega Dreamcast, working on providing a pthread layer of abstraction above our own custom kernel among a few other things in C...

And holy crap, guys, I can't believe how well this stuff works and just how quickly @darcagn was able to work his way up to having async and advanced Rust concurrency running just fine on the Sega Dreamcast with our TLS model (currently only supports local-exec), our atomics (we provide our own just toggling interrupts), and many other things...

I really think this is going to be able to bring a lot of epic Rust stuff to the SH arch, and I would love to see us getting support for our target upstreamed....

Also its's so nice to see all of you SH rockstars here and how much interest there is in bringing this cool new stuff to the target. I'll have to join the IRC server!

EDIT: @antoyo, should the "Rust on Dreamcast" article by @darcagn get added to the wiki as an SH link as well? He even bought a .rs site for his Rust Dreamcast stuff: http://dreamcast.rs. Haha.

[glaubitz]

I'm not super familiar with what exactly @darcagn had to go through to get all of this set up with rustc_codegen_gcc targeting SH4, but I have been on the KallistiOS side helping to support the back-end needs for the Rust stdlib and even tokio async library on the Sega Dreamcast, working on providing a pthread layer of abstraction above our own custom kernel among a few other things in C...

And holy crap, guys, I can't believe how well this stuff works and just how quickly @darcagn was able to work his way up to having async and advanced Rust concurrency running just fine on the Sega Dreamcast with our TLS model (currently only supports local-exec), our atomics (we provide our own just toggling interrupts), and many other things...

This gives me hope that we can get rustc_codegen_gcc get to work for alpha, hppa, m68k and sh4 in Debian as well.

I really think this is going to be able to bring a lot of epic Rust stuff to the SH arch, and I would love to see us getting support for our target upstreamed....

Also its's so nice to see all of you SH rockstars here and how much interest there is in bringing this cool new stuff to the target. I'll have to join the IRC server!

Please keep in mind that there are still a lot of open issues with the SH backend in GCC, so please help me organize a crowdfunding campaign to pay an experienced GCC developer to revamp the SH backend in GCC. The SH backend really isn't in a good shape at the moment with lots of source packages triggering ICEs.

[glaubitz]

@antoyo Are there plans to add GCC upstream as a git submodule to the rustc git tree similar to LLVM?

I think it would be great to have rustc_codegen_gcc eventually work exactly like rustc_codegen_llvm, so that in the end the build system will automatically build libgccjit for targets that have GCC backends only.

[GuillaumeGomez]

rust-lang/rust#125419

[glaubitz]

rust-lang/rust#125419

Woohoo! Awesome, thanks!

[dkm]

Looks like there's some confusion about the GPL license in the comments. Hope this won't push it back or trigger false alarm :). Nice to see it included in rustc :thumbup:

[GuillaumeGomez]

Don't hesitate to comment to clear confusion. ;)

[antoyo]

@antoyo Are there plans to add GCC upstream as a git submodule to the rustc git tree similar to LLVM?

I think it would be great to have rustc_codegen_gcc eventually work exactly like rustc_codegen_llvm, so that in the end the build system will automatically build libgccjit for targets that have GCC backends only.

I'm not sure how you want to install rustc_codegen_gcc, but the above might be to get it via rustup: would that be alright?
@GuillaumeGomez can comment to confirm.

[GuillaumeGomez]

It's the plan.

[glaubitz]

@antoyo Are there plans to add GCC upstream as a git submodule to the rustc git tree similar to LLVM?
I think it would be great to have rustc_codegen_gcc eventually work exactly like rustc_codegen_llvm, so that in the end the build system will automatically build libgccjit for targets that have GCC backends only.

I'm not sure how you want to install rustc_codegen_gcc, but the above might be to get it via rustup: would that be alright? @GuillaumeGomez can comment to confirm.

I'm not sure how that's related to rustup? I'm talking about being able to build rustc_codegen_gcc from git.

To be honest, I have never used rustup as either use distribution packages or build the compiler from git.

[GuillaumeGomez]

Nothing prevents you to build gcc from our fork.

[glaubitz]

Nothing prevents you to build gcc from our fork.

A forked GCC won't help me when I want to build a stand-alone compiler for alpha, hppa, m68k and sh4.

My hope was that rustc_codegen_gcc would soon help us to bring Rust to more architectures.

[GuillaumeGomez]

I'm getting more and more confused by what you want to do here. GCC upstream doesn't have all the patches we wrote that are needed for rust, so for now only our fork can be used with rustc_codegen_gcc. An important note about cross-compilation with GCC (I don't know how much you know about it so just in case...): GCC only allows to compile to one target. You need to compile GCC for this target on your current platform for it to be used to build cross-compilation. It's an annoying limitation and has nothing to do with Rust, so again, you need to build your own GCC. Only difference: you need to build the one from our fork (which is the submodule being added to the rust repository).

[cr1901]

So lately, I've been just lurking, but I still read this issue:

I understand that distributing libgccjit.so is more complicated than the LLVM backend because each libgccjit.so can only target one arch. Has there been movement on how all the different libgccjit.sos should coexist?

When I asked this, something that I intended to imply asking is "will upstream Rust handle building/providing libgccjits, so that a user need not compile their own"?

I take it from "Nothing prevents you to build gcc from our fork." that if someone wants to use the gcc backend, they are expected to provide their own gcc, and upstream Rust has no plans to host the libgccjit shared objects? I.e. if someone wants there to be a turnkey solution to installing the gcc backend from rustup, a third-party will have to host libgccit.so's (or some other project will need to be created for providing them all)?

[GuillaumeGomez]

When I asked this, something that I intended to imply asking is "will upstream Rust handle building/providing libgccjits, so that a user need not compile their own"?

We plan to provide libgccjit.so and gcc for the target you asked, but nothing for cross-compilation (and linux-only for now).

I take it from "Nothing prevents you to build gcc from our fork." that if someone wants to use the gcc backend, they are expected to provide their own gcc, and upstream Rust has no plans to host the libgccjit shared objects? I.e. if someone wants there to be a turnkey solution to installing the gcc backend from rustup, a third-party will have to host libgccit.so's (or some other project will need to be created for providing them all)?

Like I mentioned above, rustup will provide needed files to use the Rust GCC backend. Without rustup, it's entirely up to the user indeed.

[glaubitz]

I'm getting more and more confused by what you want to do here. GCC upstream doesn't have all the patches we wrote that are needed for rust, so for now only our fork can be used with rustc_codegen_gcc. An important note about cross-compilation with GCC (I don't know how much you know about it so just in case...): GCC only allows to compile to one target. You need to compile GCC for this target on your current platform for it to be used to build cross-compilation. It's an annoying limitation and has nothing to do with Rust, so again, you need to build your own GCC. Only difference: you need to build the one from our fork (which is the submodule being added to the rust repository).

Well, my point is that I don’t understand why the necessary patches haven’t been upstreamed yet. I don’t need a cross-compiler for all targets, I just want to be able to build stand-alone rustc for new targets. I had hoped this to be much easier as I remember this was stated as one of the big advantages over gccrs which I have already used to build minimal rust binaries for new targets.

[GuillaumeGomez]

Well, quite a lot of them are waiting for reviews. Getting things merged it taking veeeeeeery long.

[antoyo]

Well, my point is that I don’t understand why the necessary patches haven’t been upstreamed yet. I don’t need a cross-compiler for all targets, I just want to be able to build stand-alone rustc for new targets. I had hoped this to be much easier as I remember this was stated as one of the big advantages over gccrs which I have already used to build minimal rust binaries for new targets.

The usual rustc also use a forked LLVM, if I'm not mistaken. Is there any reason why this wouldn't suit you that it is the same (for the time being: in the long run, the plan is to use upstream libgccjit, but the reviews take a long time to be done)?

Could you please explain how you would want to build rustc_codegen_gcc since you seem to want something different than most people (that want to download it via rustup)? Please describe the commands you would want to write to build it.

[bjorn3]

The usual rustc also use a forked LLVM, if I'm not mistaken.

It also works with upstream LLVM. The forked LLVM just has some more bugfixes, not any actually new non-optional features.

[cr1901]

Like I mentioned above

Yea, it occurred to me that I asked my question prematurely and hoped you wouldn't notice :P.

Like I mentioned above, rustup will provide needed files to use the Rust GCC backend. Without rustup, it's entirely up to the user indeed.

All of this is perfectly fine with me. I have scripts (actually a Rust crate using rust_cmd_lib) to build LLVM and rustc from git. I have plans to add building libgccjit from it as well.

My scripts assume a shared external LLVM checkout that I use for other projects, and has logic to handle swapping between upstream and Rust branches. Plan would be to do the same for the forked gcc repo. @glaubitz if your concern is not having 10 million gcc and llvm checkouts, I've used my script successfully for ~2 years now, building Rust once a week, and should probably open-source it. It's like 300 lines of Rust if that, and is mainly Rust to handle the git checkout logic.

We plan to provide libgccjit.so and gcc for the target you asked, but nothing for cross-compilation (and linux-only for now).

FWIW, in my initial post, I asked for bare-metal SuperH target. So we're getting SuperH support in rustup :P?