Do you also need some fixes to use the correct linker?

Thank you so much for doing this! This is dearly needed and I am really looking forward to be able to bootstrap rustc on the remaining four architectures in Debian!

Do you also need some fixes to use the correct linker?

We can use mold on m68k and sh4 but we have to use ld.bfd on alpha and hppa. (alpha used to be supported in mold but it got removed, for hppa there is a WIP branch).

CC @danglin44 @gyrovorbis @hdeller @maciej-w-rozycki @rth7680 @sozud

Thank you SO MUCH for this from the Sega Dreamcast community as well...

Trust me, there are a WHOLE lot of us on "tier 3" devices who are still using the latest GCC 15.x and are drooling over potentially having Rust support... Truly, thank you.

Hi, I was wondering: Has there been any progress on this?

@glaubitz: As far as I know, there's not been any progress on this recently.
I do plan to start working on compiling rustc for m68k soon, though.
But for now, I'm sending patches to GCC in order to have them merged for the next release, hopefully.

I've started filing bugs and playing with using rustc_codegen_gcc on x86_64. Too soon to think about others for me yet.

Hi, I was wondering: Has there been any progress on this?

I sadly was unable to get something merge-able before the end of GSoC, and I am now far too busy with other things to pour any more time into this.

We had a discussion with @glaubitz on this mailing list.

I wanted to answer here to keep the discussion in one place.

I assume you're talking about this:

https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec/targets

How do I actually determine the data layout for non-LLVM architectures?

Yes.
The rust compiler uses the same data layout strings as LLVM, so you can build own using the doc.

• Add handling of the Alpha ABI to the Rust compiler

I assume you're talking about the calling convention?

https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/callconv

Yes. Sorry I didn't added the links you can see in the original post of this issue in my email on the mailing list.

I have added both for several targets and I can certainly do that for Alpha, HPPA
and SuperH. I just need to understand how to wire architectures up when they don't
have an LLVM backend.

Are you referring to our discussion we had here?
If so, I believe we were at the point of opening an MCP to add a target only supported by GCC.
Would @glaubitz or @thesamesam be interested in creating such an MCP?
There was an example of an MCP adding a tier-3 target here.
Opening such an MCP should at least trigger the discussion we need to have regarding adding a GCC-only target.

• Add Alpha to the code inserting metadata into object files

Which code part is this? Are you talking about the object crate?

Sorry, I didn't link this either in my email. The link is above in the original post.

• Add Alpha as a recognized architecture to be used in
  #[cfg(target_arch = "alpha")].
• Add Alpha support to libc.

I can do that as well.

Thanks a lot.
As mentioned, I'm first focusing on m68k, but I'll move to DEC Alpha when it is done.

Would @glaubitz or @thesamesam be interested in creating such an MCP?

I am interested. I just want to get amd64 working well enough first so I am not proposing lots before I know what I am doing. Probably HPPA as it's the one I have the most interest in, but I am open to the others too. I can also do some together with @glaubitz (maybe the first one and then others we can divide up, dunno).

Nice. Thank you.
I guess we should write a draft somewhere first to be able to review it to make sure we don't forget some things like the required change in Rust to mention that a specific target only works with the GCC codegen.

I have just looked into adding m68k support to rustix and linux-raw-sys and it seems to me that those packages basically duplicate the functionality of the libc crate.

Plus, it seems one needs clang for a given target architecture to auto-generate code in linux-raw-sys, is that right?

The generated bindings seem to be checked into the repo. Does building the crate require regenerating them? As long as it doesn't, we're fine.

linux-raw-sys contains a separate set of bindings for every architecture given that various types have different definitions between architectures. So while you don't need to regenerate the bindings while building linux-raw-sys, you do need to generate them once for the target architecture first, which needs libclang support for the architecture as that is what rust-bindgen is built on top of.

which needs libclang support for the architecture as that is what rust-bindgen is built on top of.

Is that actually true? I would assume that you can just generate the bindings on x86_64 even for other architectures when you have the kernel source checked out. I don't assume that bindgen has to be run natively for the architecture you want to add, does it?

Ah, I'd assumed libclang was used for generation from some definitions of types and such in Rust (and therefore just libclang on another platform would be sufficient). That's going to be a problem then...

Where is the actual requirement coming from here? The kernel doesn't rely on C standard library types, so I guess it comes from the right preprocessor macros being set (and perhaps sizeof(...)) giving the results needed? But for almost all of it, they should be references to some type which is defined in a handful of places.

I don't assume that bindgen has to be run natively for the architecture you want to add, does it?

I meant that libclang has to have support for analyzing code for the target architecture, not that libclang itself must be built for the target architecture.

I don't assume that bindgen has to be run natively for the architecture you want to add, does it?

I meant that libclang has to have support for analyzing code for the target architecture, not that libclang itself must be built for the target architecture.

OK, but that would defeat the whole purpose of GCC-based code generation backends. Can we do this differently?

And is libclang actually used for parsing assembler code?

And is libclang actually used for parsing assembler code?

No. It is only used by rust-bindgen for parsing C headers and expanding preprocessor macros to extract type definitions and function declarations (and experimentally to parse function bodies for inline functions, but I don't expect linux-raw-sys to depend on that).

Can we do this differently?

Either rust-bindgen would need to gain a C parser and pre-processor written in Rust, or it would need to gain a GCC backend: rust-lang/rust-bindgen#1949 Or maybe in the case of linux-raw-sys you can hack your way around it with a whole bunch of #defines and then telling libclang that you are compiling for a known target?

And is libclang actually used for parsing assembler code?

It's needed to figure out what some arbitrary C type actually is. A simple example is int* a in some struct. What's the size of that struct? You need to know the size of int* on that target.

Or maybe in the case of linux-raw-sys you can hack your way around it with a whole bunch of #defines and then telling libclang that you are compiling for a known target?

That's what I was thinking, but I'm also looking at whether we can get away with some small support in Clang (without an LLVM backend). TCE.{h,cpp} is a small example.

Meh, that used to work without having clang support when there was just libc. More work then. :(

I have just looked into adding m68k support to rustix and linux-raw-sys and it seems to me that those packages basically duplicate the functionality of the libc crate.

Would it be possible to generate these bindings manually by taking what's in libc and adjusting the code if needed?

For a subset yes. Most things in linux-raw-sys are not exported by libc however. Perhaps patching rustix to always enable the use-libc feature and to remove the linux-raw-sys dependency would be easier?

I have asked the linux-raw-sys project now to provide instructions on how to add a new target here.

I have asked the linux-raw-sys project now to provide instructions on how to add a new target here.

Thanks.

I believe I'm at the point where I need this for compiling rustc for m68k:

error[E0432]: unresolved import `crate::general`
    --> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/linux-raw-sys-0.9.4/src/lib.rs:166:16
     |
 166 |     use crate::general::__kernel_fd_set;
     |                ^^^^^^^ could not find `general` in the crate root
     |
note: found an item that was configured out
    --> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/linux-raw-sys-0.9.4/src/lib.rs:239:9
     |
 237 | #[cfg(target_arch = "arm")]
     |       ------------------- the item is gated behind the `arm` feature
 238 | #[path = "arm/general.rs"]
 239 | pub mod general;
     |         ^^^^^^^
note: found an item that was configured out
    --> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/linux-raw-sys-0.9.4/src/lib.rs:319:9
     |
 317 | #[cfg(target_arch = "aarch64")]
     |       ----------------------- the item is gated behind the `aarch64` feature
 318 | #[path = "aarch64/general.rs"]
 319 | pub mod general;
     |         ^^^^^^^
note: found an item that was configured out
    --> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/linux-raw-sys-0.9.4/src/lib.rs:399:9
     |
 397 | #[cfg(target_arch = "csky")]
     |       -------------------- the item is gated behind the `csky` feature
 398 | #[path = "csky/general.rs"]
 399 | pub mod general;
     |         ^^^^^^^

[…]

I'll try to workaround this for now.