Hello,

here is a quick summary of what needs to be done to get a working Rust comp iler for m68k
on Linux. Most of the changes apply to NetBSD as well, except for the align ment issues as
NetBSD is already using a 32-bit alignment on m68k by default.

Speaking of which, the default 16-bit alignment on Linux on m68k is still o
ne of the biggest
blockers for Rust on m68k on Linux and it's also what currently prevents ma
ny other packages
from being built on Debian unstable on m68k [1][2].

Since switching the default alignment to 32 bits would break the kernel ABI
, it has been
proposed to make the kernel ABI alignment-agnostic first [3]. This would al
low the kernel
to be built with either alignment without breaking the alignment. An initia
l patch series
was proposed by Arnd Bergmann.

Once the alignment issue has been sorted out, the next issue to address is
the lack of the
M68k backend in LLVM to handle 32-bit offsets for variables and jumps [4]. Currently, the
backend will always generate 16-bit offsets which is not enough to compile
all Rust code,
although some Rust code compiles also with 16-bit offsets.

I have created a rough patch to add support for 32-bit offsets with the hel
p of Gemini but
the patch has multiple problems as outlined in the GitHub issue in [4]. One
of the problems
is that it creates the 32-bit offsets in an inefficient way as if the targe
t was a ColdFire
CPU. However, the original 680x0 CPUs can actually use more efficient code
to address 32-bit
variables and jumps. The inefficient way would still be used when ColdFire support gets added
to LLVM though [5].

With these changes implemented, all that would be left - to my current - kn owledge would be
to update the Rust crates ¯cc® [6] and ¯linux-raw-sys®
[7] to make the Rust compiler build
on Linux on m68k.

If anyone wants to help getting Rust to work on m68k, please let me know!

Thanks,
Adrian

[1] https://wiki.debian.org/M68k/Alignment
[2] https://github.com/M680x0/issues/issues/3
[3] https://github.com/M680x0/issues/issues/6
[4] https://github.com/llvm/llvm-project/issues/181481
[5] https://github.com/M680x0/issues/issues/4
[6] https://github.com/rust-lang/rust/issues/155602
[7] https://github.com/rust-lang/rust/issues/155603

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Thu, 2026-04-23 at 09:39 +0200, John Paul Adrian Glaubitz wrote:

Once the alignment issue has been sorted out, the next issue to address i

s the lack of the

M68k backend in LLVM to handle 32-bit offsets for variables and jumps [4]

. Currently, the

backend will always generate 16-bit offsets which is not enough to compil

e all Rust code,

although some Rust code compiles also with 16-bit offsets.

I have created a rough patch to add support for 32-bit offsets with the h

elp of Gemini but

the patch has multiple problems as outlined in the GitHub issue in [4]. O

ne of the problems

is that it creates the 32-bit offsets in an inefficient way as if the tar

get was a ColdFire

CPU. However, the original 680x0 CPUs can actually use more efficient cod

e to address 32-bit

variables and jumps. The inefficient way would still be used when ColdFir

e support gets added

to LLVM though [5].

I have used Google Gemini Code Assist now [1] in order to create a patch to
add support for 32-bit
relocations to the LLVM M68k backend. This time, the code makes use of the full capabilities of
68020+ CPUs and does not the inefficient four-instruction method to impleme
nt 32-bit accesses.

I'm hesitant to send this in for review as this was basically written by Ge mini under my supervision
with a lot of testing of build tests.

Adrian

[1] https://github.com/llvm/llvm-project/issues/181481#issuecomment-44769

33700

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: First successful cargo build - Re: Summary on what's blocking full Rust support on m68k

Hi,

On Mon, 2026-05-18 at 15:03 +0200, John Paul Adrian Glaubitz wrote:

I have used Google Gemini Code Assist now [1] in order to create a patch

to add support for 32-bit

relocations to the LLVM M68k backend. This time, the code makes use of th

e full capabilities of

68020+ CPUs and does not the inefficient four-instruction method to imple

ment 32-bit accesses.

I'm hesitant to send this in for review as this was basically written by

Gemini under my supervision

with a lot of testing of build tests.

I was eventually able to build cargo for m68k-unknown-linux-gnu:

(unstable-amd64-sbuild)glaubitz@esk:~/rust/build$ file ./x86_64-unknown-lin ux-gnu/stage2-tools/m68k-unknown-linux-gnu/release/cargo ./x86_64-unknown-linux-gnu/stage2-tools/m68k-unknown-linux-gnu/release/carg
o: ELF 32-bit MSB pie executable, Motorola m68k, 68020, version 1 (SYSV), d ynamically linked, interpreter /lib/ld.so.1, BuildID[sha1]=7e5bf08930f87b9eaee173cf163b067f620cb841, for GNU/Linux 3.2
.0, not stripped
(unstable-amd64-sbuild)glaubitz@esk:~/rust/build$

The binary runs on m68k but there is no output, unfortunately. Needs more d ebugging.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)