tools/include/nolibc/arch-m68k.h | 141 +++++++++++++++++++++++++++++++ tools/include/nolibc/arch.h | 2 + 2 files changed, 143 insertions(+) create mode 100644 tools/include/nolibc/arch-m68k.h
From: Daniel Palmer <daniel@thingy.jp>
Add nolibc support for m68k. Should be helpful for nommu where
linking libc can bloat even hello world to the point where you get
an OOM just trying to load it.
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
tools/include/nolibc/arch-m68k.h | 141 +++++++++++++++++++++++++++++++
tools/include/nolibc/arch.h | 2 +
2 files changed, 143 insertions(+)
create mode 100644 tools/include/nolibc/arch-m68k.h
diff --git a/tools/include/nolibc/arch-m68k.h b/tools/include/nolibc/arch-m68k.h
new file mode 100644
index 000000000000..6dac1845f298
--- /dev/null
+++ b/tools/include/nolibc/arch-m68k.h
@@ -0,0 +1,141 @@
+/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
+/*
+ * m68k specific definitions for NOLIBC
+ * Copyright (C) 2025 Daniel Palmer<daniel@thingy.jp>
+ *
+ * Roughly based on one or more of the other arch files.
+ *
+ */
+
+#ifndef _NOLIBC_ARCH_M68K_H
+#define _NOLIBC_ARCH_M68K_H
+
+#include "compiler.h"
+#include "crt.h"
+
+#define _NOLIBC_SYSCALL_CLOBBERLIST "memory"
+
+#define my_syscall0(num) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r"(_num) \
+ : "r"(_num) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+#define my_syscall1(num, arg1) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ register long _arg1 __asm__ ("d1") = (long)(arg1); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r"(_num) \
+ : "r"(_arg1) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+#define my_syscall2(num, arg1, arg2) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ register long _arg1 __asm__ ("d1") = (long)(arg1); \
+ register long _arg2 __asm__ ("d2") = (long)(arg2); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r"(_num) \
+ : "r"(_arg1), "r"(_arg2) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+#define my_syscall3(num, arg1, arg2, arg3) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ register long _arg1 __asm__ ("d1") = (long)(arg1); \
+ register long _arg2 __asm__ ("d2") = (long)(arg2); \
+ register long _arg3 __asm__ ("d3") = (long)(arg3); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r"(_num) \
+ : "r"(_arg1), "r"(_arg2), "r"(_arg3) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+#define my_syscall4(num, arg1, arg2, arg3, arg4) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ register long _arg1 __asm__ ("d1") = (long)(arg1); \
+ register long _arg2 __asm__ ("d2") = (long)(arg2); \
+ register long _arg3 __asm__ ("d3") = (long)(arg3); \
+ register long _arg4 __asm__ ("d4") = (long)(arg4); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r" (_num) \
+ : "r"(_arg1), "r"(_arg2), "r"(_arg3), "r"(_arg4) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+#define my_syscall5(num, arg1, arg2, arg3, arg4, arg5) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ register long _arg1 __asm__ ("d1") = (long)(arg1); \
+ register long _arg2 __asm__ ("d2") = (long)(arg2); \
+ register long _arg3 __asm__ ("d3") = (long)(arg3); \
+ register long _arg4 __asm__ ("d4") = (long)(arg4); \
+ register long _arg5 __asm__ ("d5") = (long)(arg5); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r" (_num) \
+ : "r"(_arg1), "r"(_arg2), "r"(_arg3), "r"(_arg4), "r"(_arg5) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6) \
+({ \
+ register long _num __asm__ ("d0") = (num); \
+ register long _arg1 __asm__ ("d1") = (long)(arg1); \
+ register long _arg2 __asm__ ("d2") = (long)(arg2); \
+ register long _arg3 __asm__ ("d3") = (long)(arg3); \
+ register long _arg4 __asm__ ("d4") = (long)(arg4); \
+ register long _arg5 __asm__ ("d5") = (long)(arg5); \
+ register long _arg6 __asm__ ("a0") = (long)(arg6); \
+ \
+ __asm__ volatile ( \
+ "trap #0\n" \
+ : "+r" (_num) \
+ : "r"(_arg1), "r"(_arg2), "r"(_arg3), "r"(_arg4), "r"(_arg5), \
+ "r"(_arg6) \
+ : _NOLIBC_SYSCALL_CLOBBERLIST \
+ ); \
+ _num; \
+})
+
+void _start(void);
+void __attribute__((weak, noreturn)) __nolibc_entrypoint __no_stack_protector _start(void)
+{
+ __asm__ volatile (
+ "movel %sp, %sp@-\n"
+ "jsr _start_c\n"
+ );
+ __nolibc_entrypoint_epilogue();
+}
+
+#endif /* _NOLIBC_ARCH_M68K_H */
diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
index 8a2c143c0fba..ba3da0f098f1 100644
--- a/tools/include/nolibc/arch.h
+++ b/tools/include/nolibc/arch.h
@@ -33,6 +33,8 @@
#include "arch-s390.h"
#elif defined(__loongarch__)
#include "arch-loongarch.h"
+#elif defined(__m68k__)
+#include "arch-m68k.h"
#else
#error Unsupported Architecture
#endif
--
2.49.0Hi Daniel, On Sat, Apr 26, 2025 at 01:12:12PM +0900, Daniel Palmer wrote: > From: Daniel Palmer <daniel@thingy.jp> > > Add nolibc support for m68k. Should be helpful for nommu where > linking libc can bloat even hello world to the point where you get > an OOM just trying to load it. Nice, thank you! Could you please also add support for it to tools/testing/selftests/nolibc/ and verify that it works ? We heavily rely on it to make sure we don't break nolibc along changes. You may possible have to add a few ifndef, as I don't think we've ever had a nommu platform yet. If you face too many failures or just difficulties, please let us know so that we can figure together a suitable solution. Thanks, Willy
Hi Willy, On Sat, 26 Apr 2025 at 14:14, Willy Tarreau <w@1wt.eu> wrote: > Nice, thank you! Could you please also add support for it to > tools/testing/selftests/nolibc/ and verify that it works ? Sure, doing that now. For now it'll be using the mmu enabled m68k virt machine that QEMU supports out of the box. > changes. You may possible have to add a few ifndef, as I don't > think we've ever had a nommu platform yet. If you face too many > failures or just difficulties, please let us know so that we can > figure together a suitable solution. I need to test actually building and running something for nommu but I will do that later today. Making nommu test automatically might be a bit difficult though as I think it only really works with some changes I have to linux and QEMU. Cheers, Daniel
Hi Daniel, On 26/4/25 16:16, Daniel Palmer wrote: > Hi Willy, > > On Sat, 26 Apr 2025 at 14:14, Willy Tarreau <w@1wt.eu> wrote: >> Nice, thank you! Could you please also add support for it to >> tools/testing/selftests/nolibc/ and verify that it works ? > > Sure, doing that now. For now it'll be using the mmu enabled m68k virt > machine that QEMU supports out of the box. > >> changes. You may possible have to add a few ifndef, as I don't >> think we've ever had a nommu platform yet. If you face too many >> failures or just difficulties, please let us know so that we can >> figure together a suitable solution. > > I need to test actually building and running something for nommu but I > will do that later today. > Making nommu test automatically might be a bit difficult though as I > think it only really works with some changes I have to linux and QEMU. It works out-of-the-box for m68k qemu and a mainline kernel configured for m5208evb_defconfig - when using the qemu "mcf5208evb" machine. That is a nommu m68k/coldfire variant. Regards Greg
Hi Greg, On Sat, 26 Apr 2025 at 21:38, Greg Ungerer <gerg@kernel.org> wrote: > > I need to test actually building and running something for nommu but I > > will do that later today. > > Making nommu test automatically might be a bit difficult though as I > > think it only really works with some changes I have to linux and QEMU. > > It works out-of-the-box for m68k qemu and a mainline kernel configured > for m5208evb_defconfig - when using the qemu "mcf5208evb" machine. > That is a nommu m68k/coldfire variant. Ok, I didn't realise there was any working nommu machine in mainline QEMU. Does direct kernel booting with a ramdisk work there? The tests for nolibc require that. Either way, I'll it out tomorrow. Thanks, Daniel
Hi Daniel, On 26/4/25 23:06, Daniel Palmer wrote: > Hi Greg, > > On Sat, 26 Apr 2025 at 21:38, Greg Ungerer <gerg@kernel.org> wrote: >>> I need to test actually building and running something for nommu but I >>> will do that later today. >>> Making nommu test automatically might be a bit difficult though as I >>> think it only really works with some changes I have to linux and QEMU. >> >> It works out-of-the-box for m68k qemu and a mainline kernel configured >> for m5208evb_defconfig - when using the qemu "mcf5208evb" machine. >> That is a nommu m68k/coldfire variant. > > Ok, I didn't realise there was any working nommu machine in mainline QEMU. > Does direct kernel booting with a ramdisk work there? The tests for > nolibc require that. > Either way, I'll it out tomorrow. Direct kernel booting with builtin root init ramfs works. The defconfing is not configured that way, but I always run it with CONFIG_INITRAMFS_SOUCRE set to a suitable rootfs. Regards Greg
On Sat, Apr 26, 2025 at 03:16:35PM +0900, Daniel Palmer wrote: > Hi Willy, > > On Sat, 26 Apr 2025 at 14:14, Willy Tarreau <w@1wt.eu> wrote: > > Nice, thank you! Could you please also add support for it to > > tools/testing/selftests/nolibc/ and verify that it works ? > > Sure, doing that now. For now it'll be using the mmu enabled m68k virt > machine that QEMU supports out of the box. Ah, I didn't know that there's both mmu and nommu for m68k :-) > > changes. You may possible have to add a few ifndef, as I don't > > think we've ever had a nommu platform yet. If you face too many > > failures or just difficulties, please let us know so that we can > > figure together a suitable solution. > > I need to test actually building and running something for nommu but I > will do that later today. > Making nommu test automatically might be a bit difficult though as I > think it only really works with some changes I have to linux and QEMU. OK no worries, my point really is that it's important to implement the test for the target platform. If it's mmu only that's fine, as it will ensure we don't break it in future updates. thanks, Willy
Hi Willy, On Sat, 26 Apr 2025 at 15:56, Willy Tarreau <w@1wt.eu> wrote: > OK no worries, my point really is that it's important to implement the > test for the target platform. If it's mmu only that's fine, as it will > ensure we don't break it in future updates. I sent a v2 that adds the tests to run on the QEMU virt machine and seems to pass. I tried the user mode as well and that passed also. Thanks, Daniel
© 2016 - 2026 Red Hat, Inc.