For now, it seems like those 4 are the only remaining issues that stop us from getting rustc on that plaform.

Working around them, I got a build of rustc for m68k.

For now, it seems like those 4 are the only remaining issues that stop us from getting rustc on that plaform.

Working around them, I got a build of rustc for m68k.

Wow, amazing! I guess you can also then add support for alpha, hppa and sh4 ;-).

FWIW, in case you're running into alignment issues with m68k, you can use 32-bit alignment as this is the alignment we want to use in the future on Linux/m68k and which is also the default alignment according to the official ELF ABI specification.

Wow, amazing! I guess you can also then add support for alpha, hppa and sh4 ;-).

Sadly, any upstream support will have to wait for an MCP about adding the alpha / hppa / sh4 target. There is nothing I can do in this area: I can't maintain those targets, and I have to wait until the interested parties create a MCP.

Wow, amazing! I guess you can also then add support for alpha, hppa and sh4 ;-).

Sadly, any upstream support will have to wait for an MCP about adding the alpha / hppa / sh4 target. There is nothing I can do in this area: I can't maintain those targets, and I have to wait until the interested parties create a MCP.

Can you elaborate on this a little more? Has it become more complicated adding new targets? What's an MCP?

Back when I added m68k-unknown-linux-gnu, powerpc-unknown-linux-gnuspe and sparc-unknown-linux-gnu it was a matter of creating a PR.

I sent a message about this here - guess it just got buried.

The TLDR is that adding a tier 3 target requires a MCP, like this one, for example.

A MCP issue is kind of like the PRs you'd send before(I think, unless the process changed a lot). If nobody voices concern about adding Alpha, and one of the Rust devs agrees to help facilitate/oversee the work, the MCP gets accepted after 10 days.

At that point, we have all the blessings to start compiler-side work, and get it merged. This way, we also avoid the repeat of the hppa situation - the target can't be removed as easily.

@FractalFir Could you share the m68k rustc binaries with me for testing?

And did you also manage to build cargo?

Building cargo ATM - will see if it works out. Once that is done, I will share the tar.gz files with you.

Also, you I think you will need to build libgccjit from our repo. That contains the needed patches.

cargo depends on openSSL, and that is causing a lot of build problems.

For now, here is the Rust for m68k without cargo: https://drive.google.com/file/d/1jF30QJUbDHqvRfjzwXrg4K-oTpLEGqO-/view?usp=sharing

With this rustc, can you successfully compile a "Hello, world!" (using the std) for m68k?

Not yet - I don't have libgccjit.so for m68k.

With a mock libgccjit.so, I am able to check the no_core test file on m68k.

So, we now know that everything up to codegen works.

Codegen fails, due to GenericArgKind not being sufficiently aligned.

assert_eq!(align_of_val(&*lt.0.0) & TAG_MASK, 0);

With a mock libgccjit.so, I am able to check the no_core test file on m68k.

So, we now know that everything up to codegen works.

Codegen fails, due to GenericArgKind not being sufficiently aligned.

assert_eq!(align_of_val(&*lt.0.0) & TAG_MASK, 0);

Well, I was actually expecting that. It's the main reason why I'm working to switch Linux/m68k to 32-bit alignment. The linked wiki page contains a patch to switch GCC to 32-bit alignment on Linux/m68k.

Please patch rustc to use 32-bit alignment on m68k-unknown-linux-gnu by default and don't bother about the broken alignment.

Once you have everything in place, I will take care of the alignment discussion with GCC upstream.

I'm only lurking here, but when the build is easily reproducible and working, feel free to ping me to add it to compiler explorer (I tried 3 years ago compiler-explorer/compiler-explorer#3760 without success, but would be happy to resurrect the task)

I'm only lurking here, but when the build is easily reproducible and working, feel free to ping me to add it to compiler explorer (I tried 3 years ago compiler-explorer/compiler-explorer#3760 without success, but would be happy to resurrect the task)

Just to make sure, do you want a cross-compiler or a native compiler?

I'm only lurking here, but when the build is easily reproducible and working, feel free to ping me to add it to compiler explorer (I tried 3 years ago compiler-explorer/compiler-explorer#3760 without success, but would be happy to resurrect the task)

Just to make sure, do you want a cross-compiler or a native compiler?

A cross compiler. We're mainly running things on common ubuntu/intel hosts. We have some aarch64 runners, but it's not the main thing, and won't help here anyway 😅

I'm only lurking here, but when the build is easily reproducible and working, feel free to ping me to add it to compiler explorer (I tried 3 years ago compiler-explorer/compiler-explorer#3760 without success, but would be happy to resurrect the task)

Just to make sure, do you want a cross-compiler or a native compiler?

A cross compiler. We're mainly running things on common ubuntu/intel hosts. We have some aarch64 runners, but it's not the main thing, and won't help here anyway 😅

Cross compilation has worked for a couple of months now. There have been some breakages recently(related to a rustc refactor), but those ought to be fully fixed soon.

We compile & run m68k executables in our CI:
https://github.com/rust-lang/rustc_codegen_gcc/blob/master/.github/workflows/m68k.yml

I'm only lurking here, but when the build is easily reproducible and working, feel free to ping me to add it to compiler explorer (I tried 3 years ago compiler-explorer/compiler-explorer#3760 without success, but would be happy to resurrect the task)

Just to make sure, do you want a cross-compiler or a native compiler?

A cross compiler. We're mainly running things on common ubuntu/intel hosts. We have some aarch64 runners, but it's not the main thing, and won't help here anyway 😅

Cross compilation has worked for a couple of months now. There have been some breakages recently(related to a rustc refactor), but those ought to be fully fixed soon.

We compile & run m68k executables in our CI: https://github.com/rust-lang/rustc_codegen_gcc/blob/master/.github/workflows/m68k.yml

Oh, nice to hear. Sorry if I'm a little late 😅 I'll see how to port that on our sides! Thanks!

@dkm: It is to be noted, though, that this doesn't work as well as it used to.
We would need to add the support for m68k in this method first and then do a sync.
So, I suggest you wait a bit before trying adding the support for m68k.

My PR with this is waiting for review.

rust-lang/rust#144640

Any progress on this? I recently landed adding the m68k-unknown-linux-gnu target in cc-rs, so that building a rustc cross-compiler fails on m68k during the linking stage.

We still need to add support for large GOTs in LLVM to get this addressed.

Got knocked out by a cold for a week or so - so not much progress for now.

Right now, I plan on trying your aligment-fixing patch.

Do you have any images(for VMs) of Debian with this patch applied? And do you have a patched version of qemu somewhere?

From reading the links you have sent, I'll need a slightly modified version of those to fix the alignment issue.

I also tried the other approach(of just patching rustc to work with lower alignment) an that seems feasible, albeit not trivial. Rustc does not use too many bit-fiddling hacks, but the alignment is still an issue in a few spots.

For cargo, we need to cross-compile OpenSSL too, which is a bit of a pain.

I am also working on fixing some other, unrelated problems upstream.

I have a partially built Debian unstable for m68k with these changes that I created with the help of rebootstrap.

Alternatively, you can use this Gentoo chroot which was built with 32-bits alignment.

While QEMU has the alignment in its code, I did not have any problems with an unpatched QEMU.

I think you should just use the Gentoo chroot. It works out of the box with 32-bits alignment.

esk / # cat align.c 
#include <stdio.h>
#include <stdlib.h>

#define offsetof(type, member) ((size_t)(unsigned long)(&((type *)0)->member))

struct test { char x; int y; };

int main()
{
    printf("struct test { char x; int y; };\n");
    printf("sizeof(sturct test) = %d\n", sizeof(struct test));
    printf("offsetof(struct test, y) = %d\n", offsetof(struct test, y));
}
esk / # gcc -o align align.c
esk / # ./align 
struct test { char x; int y; };
sizeof(sturct test) = 8
offsetof(struct test, y) = 4
esk / #

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

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

• The bootstrap script fails to compile native GCC for m68k.

Do you have a bug reference for this?

No, this is only listed in the original message of this issue.
Do you plan to build libgccjit yourself or let the bootstrap script from the Rust project build it for you?
If you plan to build it yourself, then this is not really a problem. I'm in the process of trying to cross-compile rustc for m68k and I already have a WIP commit to specify where to look for a libgccjit.so depending on the target arch.

• Possibly some alignment fixes for m68k either on the Rust side or on
  the distro side (which wanted to switch to an alignment of 4 for pointers).

I need to perform some more tests with 32-bit alignment before we can make the
switch in Debian. But it's definitely work-in-progress.

So, on the Rust side, do we need to change the alignment in the target file?
I see p:32:16:32 here. Does it need to be p:32:32:32?

Also, I don't know if this is related, but I might need help with these errors that I have when building the Rust library artifacts for m68k:

  = note: /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.04ll2i4z9m016vpidsrh08afr.0rr2uu9.rcgu.o: in function `std::thread::current::set_current':
          /home/user/projects/rust/library/std/src/thread/current.rs:118:(.text._ZN3std6thread7current11set_current17h8dfbdf6be4d06606E+0xc): relocation truncated to fit: R_68K_GOT16 against symbol `_GLOBAL_OFFSET_TABLE_' defined in .got.plt section in /home/user/x-tools/m68k-unknown-linux-gnu/usr/m68k-unknown-linux-gnu/sysroot/usr/lib/crti.o
          /home/user/projects/rust/library/std/src/thread/current.rs:119:(.text._ZN3std6thread7current11set_current17h8dfbdf6be4d06606E+0x22): relocation truncated to fit: R_68K_PLT16 against symbol `std::sys::thread_local::native::LocalPointer::get' defined in .text._ZN3std3sys12thread_local6native12LocalPointer3get17ha9be6584ba7a57c6E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.92rd58b9q8rxub9etdtbv3za4.0rr2uu9.rcgu.o
          /home/user/projects/rust/library/std/src/thread/current.rs:131:(.text._ZN3std6thread7current11set_current17h8dfbdf6be4d06606E+0x80): relocation truncated to fit: R_68K_PC16 against symbol `std::sys::thread_local::guard::key::enable' defined in .text._ZN3std3sys12thread_local5guard3key6enable17h2ce01728628ee600E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.0znjx0k3i02mqkbvr18sqa07o.0rr2uu9.rcgu.o
          /home/user/projects/rust/library/std/src/thread/current.rs:132:(.text._ZN3std6thread7current11set_current17h8dfbdf6be4d06606E+0x94): relocation truncated to fit: R_68K_PC16 against symbol `std::sys::thread_local::native::LocalPointer::set' defined in .text._ZN3std3sys12thread_local6native12LocalPointer3set17he11dac467d0c2ed8E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.92rd58b9q8rxub9etdtbv3za4.0rr2uu9.rcgu.o
          /home/user/projects/rust/library/std/src/thread/current.rs:134:(.text._ZN3std6thread7current11set_current17h8dfbdf6be4d06606E+0xae): relocation truncated to fit: R_68K_PC16 against symbol `core::ptr::drop_in_place<std::thread::Thread>' defined in .text._ZN4core3ptr40drop_in_place$LT$std..thread..Thread$GT$17h6002ecb290ca67a0E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.948g8gjtlk41onfbkpli8w4gr.0rr2uu9.rcgu.o
          /home/user/projects/rust/library/std/src/thread/current.rs:118:(.text._ZN3std6thread7current11set_current17h8dfbdf6be4d06606E+0xb8): relocation truncated to fit: R_68K_PLT16 against symbol `core::panicking::panic_in_cleanup' defined in .text.unlikely._ZN4core9panicking16panic_in_cleanup17h534e0b02e7d082a3E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/libcore-9462b8fb70287567.rlib(core-9462b8fb70287567.4kcol0hgxnc682f3p2oq5g53v.0hlkvgl.rcgu.o)
          /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.04ll2i4z9m016vpidsrh08afr.0rr2uu9.rcgu.o: in function `std::thread::current::drop_current':
          /home/user/projects/rust/library/std/src/thread/current.rs:300:(.text._ZN3std6thread7current12drop_current17hc514eb8deee69fe0E+0xc): relocation truncated to fit: R_68K_GOT16 against symbol `_GLOBAL_OFFSET_TABLE_' defined in .got.plt section in /home/user/x-tools/m68k-unknown-linux-gnu/usr/m68k-unknown-linux-gnu/sysroot/usr/lib/crti.o
          /home/user/projects/rust/library/std/src/thread/current.rs:301:(.text._ZN3std6thread7current12drop_current17hc514eb8deee69fe0E+0x1e): relocation truncated to fit: R_68K_PLT16 against symbol `std::sys::thread_local::native::LocalPointer::get' defined in .text._ZN3std3sys12thread_local6native12LocalPointer3get17ha9be6584ba7a57c6E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.92rd58b9q8rxub9etdtbv3za4.0rr2uu9.rcgu.o
          /home/user/projects/rust/library/std/src/thread/current.rs:304:(.text._ZN3std6thread7current12drop_current17hc514eb8deee69fe0E+0x38): relocation truncated to fit: R_68K_PC16 against symbol `std::sys::thread_local::native::LocalPointer::set' defined in .text._ZN3std3sys12thread_local6native12LocalPointer3set17he11dac467d0c2ed8E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.92rd58b9q8rxub9etdtbv3za4.0rr2uu9.rcgu.o
          /home/user/projects/rust/library/std/src/thread/current.rs:305:(.text._ZN3std6thread7current12drop_current17hc514eb8deee69fe0E+0x3e): relocation truncated to fit: R_68K_PLT16 against symbol `std::thread::Thread::from_raw' defined in .text._ZN3std6thread6Thread8from_raw17h00de1fe7872cf246E section in /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.0dsaokh6vchqf0c5hw2k1n8n2.0rr2uu9.rcgu.o
          /home/user/projects/rust/build/x86_64-unknown-linux-gnu/stage0-std/m68k-unknown-linux-gnu/release/deps/std-c4c3a748f5f5ccea.04ll2i4z9m016vpidsrh08afr.0rr2uu9.rcgu.o: in function `std::thread::current::drop_current':
          /home/user/projects/rust/library/core/src/mem/mod.rs:967:(.text._ZN3std6thread7current12drop_current17hc514eb8deee69fe0E+0x4c): additional relocation overflows omitted from the output
          collect2: error: ld returned 1 exit status

I only get these errors in a weird case of building them with stage0, but not with stage2. I might not need to build them with stage0, but that's where I'm currently at in my attempt to build the cross-compiler.

Thanks for your help!