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

John Paul Adrian Glaubitz <[email protected]>
Newsgroups org.kernel.vger.linux-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 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 help 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 target 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].

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

Adrian

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.