Targeting an arch in gcc but not in LLVM.

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:

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?
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¹.
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

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

I'm on vacation too.

will be under discussion to see what we can do with rustup
I guess we could cross-compile the libcore tests and run them in qemu.
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.

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.

@antoyo

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?

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 ;) .

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.

@bjorn3

@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.

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.

@antoyo

@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.

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?

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.

@MabezDev

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

@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.

@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.

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.

Do you have a compleate list of arches you'd like to see supported? Some of the work(eg. making cc-rs recognize those targets) can be easily done for more than one target at a time.

It'd be excellent to get SH4 support! I've been maintaining out-of-tree Rust std/libc ports to KallistiOS (embedded OS for the SH4-based Sega Dreamcast) using rustc_codegen_gcc and (as mentioned above in 2024) hacks to make rustc believe it's work with MIPS. It's been working but difficult for end users to build, sometimes error prone due to ABI behavior mismatches, and I can't upstream the work like this.

As Adrian mentioned above, your work is highly appreciated and let me know if I can help.

After some talks to the Rust folk, in order to go forward with any compiler changes, we'd need to create a Major Change Proposal adding a tier 3 target that uses one of those ISAs.

So, if you want support for Dec Alpha or SuperH(or any other ISA), you'd need to create a MCP for those. Here is an example of such an MCP.

This would effectively get us a stamp of aproval from the people in charge, and allow the changes to land in the upstream compiler.

sometimes error prone due to ABI behavior mismatches, and I can't upstream the work like this.

Is there an official description of that ABI? That would be needed(or at least helpfull) to add support for it to Rust.

As for potentially dividing up the work:

It would be very helpful if the people familiar with the targets made the needed libc changes, and created the target files.. That is the area I am least familiar with, and one where your expertise would matter most. (This has to be done after the MCP).

I think I can handle most of the compiler-side changes: so far, they don't seem too difficult.

WRT KallistiOS, could you share your ct-ng config? Since it is known to work, I would start with that.

After some talks to the Rust folk, in order to go forward with any compiler changes, we'd need to create a Major Change Proposal adding a tier 3 target that uses one of those ISAs.

I fear this is a bit circular. I may be willing to either maintain or co-maintain a target, but I can't really get my feet wet with learning how to integrate it into Rust when I can't get anything landed. I don't want to make a major proposal change when I can't do some baby steps first...

Also, https://doc.rust-lang.org/beta/rustc/target-tier-policy.html#tier-3-target-policy says:

Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)

~~That one at least sounds hard to achieve if we can't land PRs like that HPPA one first..~~ (OK, this part seems fine maybe, since rust-lang/libc#3542 (comment) implies proposing it with a GCC backend may work, but it still has the issue I mention above?)

I don't want to make a major proposal change when I can't do some baby steps first...

Is it doable to locally build rustc with modified versions of the libc crate and so on (any advice/links/examples for that?)? If so, I can look at that.

Is there an official description of that ABI? That would be needed(or at least helpfull) to add support for it to Rust.

Yes, see document here: https://dreamcast.wiki/wiki/images/9/92/SH4_C_ABI.pdf

It would be very helpful if the people familiar with the targets made the needed libc changes

libc-0.2 crate is here in the libc-0.2-kos branch
It's a little outdated with upstream libc-0.2, but works.

and created the target files.

Available here: sh-elf.json
But of course, it says "arch": "mips", "llvm-target": "mips-unknown-linux-gnu", because no SH target exists and I "fix" that with this linker wrapper

WRT KallistiOS, could you share your ct-ng config? Since it is known to work, I would start with that.

I haven't used ct-ng to build a KallistiOS toolchain, since we have our own toolchain build scripts.
I have instructions on how to set it up available at https://dreamcast.rs/ using supporting files/patches from the repo here: https://github.com/dreamcast-rs/rust-for-dreamcast

Unfortunately, right now one of the components has a version mismatch and following those instructions will fail to compile rustc_codegen_gcc/sysroot at the final step. I need to update the components (last updated in May). But the instructions to build a GCC cross-compiler should work. I am out of office for a week or so but when I get back I can update those components so the instructions work for rustc_codegen_gcc/sysroot compilation again.

I think it would be best if those concerns were voiced to the compiler team here.

This process is a bit of a mess in this case, sadly.

Is it doable to locally build rustc with modified versions of the libc crate and so on (any advice/links/examples for that?)? If so, I can look at that.

I have a way of doing that, but it is very brittle and cursed(modifying the code in the cargo cache). You should probably ask about this in the compiler help channel. .

I will look into making this easier with cg_gcc... not sure how I'd go about this, tough.

For GCC-specific questions, you can also ask in the rustc_codegen_gcc channel.

The people here are quite helpful, so if you have any questions WRT anything related to porting rust to a new target, that is the right place. Questions are usually answered within an hour or so, sometimes up to a day(when you ask about something very specific that few people know about).

If it helps, I can outline the list of changes I made to build for DEC-alpha.

hppa-unknown-linux-gnu was already added in the past to libc but had to be removed again due to lack of compiler support..

m68k-unknown-linux-gnu is already supported by libc.

We're just missing alpha-unknown-linux-gnu then.

sometimes error prone due to ABI behavior mismatches, and I can't upstream the work like this.

Is there an official description of that ABI? That would be needed(or at least helpfull) to add support for it to Rust.

Most SysV ABI specifications can be found here.

sometimes error prone due to ABI behavior mismatches, and I can't upstream the work like this.

Is there an official description of that ABI? That would be needed(or at least helpfull) to add support for it to Rust.

Most SysV ABI specifications can be found here.

Right, I just don't know what ABI KallistiOS uses. That could pose a problem.

Right, I just don't know what ABI KallistiOS uses. That could pose a problem.

KallistiOS supports using the m4-single and m4-single-only ABIs (see SH Options). The specification document is linked above.

Found some info on using a modified libc.

https://rustc-dev-guide.rust-lang.org/building/new-target.html#patching-crates

 [patch.crates-io]
libc = {path = "my_libc_path"}

You should be able to use this modified libc without Rust compiler changes.

sometimes error prone due to ABI behavior mismatches, and I can't upstream the work like this.

Is there an official description of that ABI? That would be needed(or at least helpfull) to add support for it to Rust.

Most SysV ABI specifications can be found here.

Right, I just don't know what ABI KallistiOS uses. That could pose a problem.

I suggest implementing the Linux ABI first and then add other ABIs as necessary.

@FractalFir

I fear this is a bit circular. I may be willing to either maintain or co-maintain a target, but I can't really get my feet wet with learning how to integrate it into Rust when I can't get anything landed. I don't want to make a major proposal change when I can't do some baby steps first...

Ok, let's focus on one target at a time.
I discussed with @FractalFir and we'll focus on building a rust compiler for m68k since the target is already supported in Rust and as such, it should be the easiest.

@glaubitz: How do you intend to build the rust compiler to create the Debian package? Would you use the bootstrap script (x)? Or do you need/use another process?

I fear this is a bit circular. I may be willing to either maintain or co-maintain a target, but I can't really get my feet wet with learning how to integrate it into Rust when I can't get anything landed. I don't want to make a major proposal change when I can't do some baby steps first...

Ok, let's focus on one target at a time. I discussed with @FractalFir and we'll focus on building a rust compiler for m68k since the target is already supported in Rust and as such, it should be the easiest.

Fine with me. You can also default to 32-bit alignment as this is also the proper alignment according to the official ABI. See also this page on the Debian Wiki.

@glaubitz: How do you intend to build the rust compiler to create the Debian package? Would you use the bootstrap script (x)? Or do you need/use another process?

I'm happy with anything you can provide. Of course, it would be perfect if I could just create a host compiler by running x.py but I expect this to still take some time.

Navigation Menu

Repository navigation

Targeting an arch in gcc but not in LLVM. #49

Footnotes

70 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Targeting an arch in gcc but not in LLVM. #49

Description

Footnotes

Activity

antoyo commented on Jul 13, 2021

glaubitz commented on Jul 15, 2021

cr1901 commented on Jul 15, 2021

antoyo commented on Aug 12, 2021

bjorn3 commented on Aug 12, 2021

cr1901 commented on Aug 16, 2021

antoyo commented on Aug 20, 2021

cr1901 commented on Aug 20, 2021

MabezDev commented on Apr 1, 2022

bjorn3 commented on Apr 1, 2022

antoyo commented on Apr 1, 2022

glaubitz commented on Apr 1, 2022

MabezDev commented on Apr 1, 2022

antoyo commented on Apr 1, 2022

bjorn3 commented on Apr 1, 2022

70 remaining items

FractalFir commented on Jul 24, 2025

FractalFir commented on Jul 24, 2025

FractalFir commented on Jul 24, 2025

thesamesam commented on Jul 24, 2025

thesamesam commented on Jul 24, 2025

darcagn commented on Jul 24, 2025

FractalFir commented on Jul 24, 2025

glaubitz commented on Jul 24, 2025

glaubitz commented on Jul 24, 2025

FractalFir commented on Jul 24, 2025

darcagn commented on Jul 24, 2025

FractalFir commented on Jul 24, 2025

glaubitz commented on Jul 24, 2025

antoyo commented on Jul 26, 2025

glaubitz commented on Jul 26, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions