Re: Summary on what's blocking full Rust support on m68k

John Paul Adrian Glaubitz <[email protected]> Mon, 18 May 2026 15:03:24 +0200
Newsgroups gmane.os.netbsd.ports.m68k,gmane.linux.debian.ports.68k,gmane.linux.ports.m68k
Message-ID <6efb67b12fd971c6d38a692d7b391ce4a75b0f4a.camel@physik.fu-berlin.de>
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.
>=20
> 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

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