[PATCH] fix m68k support

[PATCH] fix m68k support

[Thorsten Glaser]

- fix syscall API and vfork
- support 6-argument syscalls
- add open/openat special handling for non-regparm arches

Signed-off-by: Thorsten Glaser <tg@mirbsd.org>
---
 usr/klibc/README.klibc        |    2 +-
 usr/klibc/SYSCALLS.def        |    4 +-
 usr/klibc/arch/m68k/Kbuild    |    1 +
 usr/klibc/arch/m68k/open.S    |   22 +++++++++++++++++++++
 usr/klibc/arch/m68k/openat.S  |   26 +++++++++++++++++++++++++
 usr/klibc/arch/m68k/syscall.S |   42 +++++++++++++++++++++++++++++++++-------
 usr/klibc/arch/m68k/vfork.S   |   13 +++--------
 usr/klibc/open.c              |    2 +-
 usr/klibc/openat.c            |    2 +-
 9 files changed, 92 insertions(+), 22 deletions(-)
 create mode 100644 usr/klibc/arch/m68k/open.S
 create mode 100644 usr/klibc/arch/m68k/openat.S

diff --git a/usr/klibc/README.klibc b/usr/klibc/README.klibc
index b4135cb..5417049 100644
--- a/usr/klibc/README.klibc
+++ b/usr/klibc/README.klibc
@@ -44,7 +44,7 @@ b) If you're cross-compiling, you need to set KLIBCARCH to the
    i386:	 Working
    ia64:	 Working static, shared untested
    m32r:	 Untested
-   m68k:	 Untested
+   m68k:	 Working
    m68knommu:	 Not yet ported
    mips:	 Working
    mips64:	 Not yet ported
diff --git a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def
index 6ed6bdf..12aef49 100644
--- a/usr/klibc/SYSCALLS.def
+++ b/usr/klibc/SYSCALLS.def
@@ -154,8 +154,8 @@ int getcwd::__getcwd(char *, size_t);
 /*
  * I/O operations
  */
-<!i386,64> int open::__open(const char *, int, mode_t);
-<?!i386,64> int openat::__openat(int, const char *, int, mode_t);
+<!i386,m68k,64> int open::__open(const char *, int, mode_t);
+<?!i386,m68k,64> int openat::__openat(int, const char *, int, mode_t);
 <64> int open(const char *, int, mode_t);
 ssize_t read(int, void *, size_t);
 ssize_t write(int, const void *, size_t);
diff --git a/usr/klibc/arch/m68k/Kbuild b/usr/klibc/arch/m68k/Kbuild
index 8d6137c..d56ae0e 100644
--- a/usr/klibc/arch/m68k/Kbuild
+++ b/usr/klibc/arch/m68k/Kbuild
@@ -3,6 +3,7 @@
 #
 
 klib-y := setjmp.o syscall.o vfork.o
+klib-y += open.o openat.o
 
 always  := crt0.o
 targets := crt0.o
diff --git a/usr/klibc/arch/m68k/open.S b/usr/klibc/arch/m68k/open.S
new file mode 100644
index 0000000..c9a7ee3
--- /dev/null
+++ b/usr/klibc/arch/m68k/open.S
@@ -0,0 +1,22 @@
+/*
+ * arch/m68k/open.S
+ *
+ * Handle the open() system call - oddball due to the varadic
+ * prototype, which forces the use of the cdecl calling convention,
+ * and the need for O_LARGEFILE.
+ */
+
+#include <asm/unistd.h>
+
+/* <asm/fcntl.h>, despite the name, isn't assembly-safe */
+#define O_LARGEFILE	0400000
+
+	.globl	open
+	.type	open,@function
+
+open:
+	or.l	# O_LARGEFILE, 8(%sp)
+	move.l	# __NR_open, %d0
+	br	__syscall_common
+
+	.size	open,.-open
diff --git a/usr/klibc/arch/m68k/openat.S b/usr/klibc/arch/m68k/openat.S
new file mode 100644
index 0000000..25d8a1a
--- /dev/null
+++ b/usr/klibc/arch/m68k/openat.S
@@ -0,0 +1,26 @@
+/*
+ * arch/m68k/openat.S
+ *
+ * Handle the openat() system call - oddball due to the varadic
+ * prototype, which forces the use of the cdecl calling convention,
+ * and the need for O_LARGEFILE.
+ */
+
+#include <asm/unistd.h>
+
+/* <asm/fcntl.h>, despite the name, isn't assembly-safe */
+#define O_LARGEFILE	0400000
+
+#ifdef __NR_openat		/* Don't build if kernel headers too old */
+
+	.globl	openat
+	.type	openat,@function
+
+openat:
+	or.l	# O_LARGEFILE, 12(%sp)
+	move.l	# __NR_openat, %d0
+	br	__syscall_common
+
+	.size	openat,.-openat
+
+#endif
diff --git a/usr/klibc/arch/m68k/syscall.S b/usr/klibc/arch/m68k/syscall.S
index 966c92d..c909e2a 100644
--- a/usr/klibc/arch/m68k/syscall.S
+++ b/usr/klibc/arch/m68k/syscall.S
@@ -11,17 +11,43 @@
 	.globl	__syscall_common
 	.type	__syscall_common, @function
 __syscall_common:
-	movem.l %d2-%d6, -(%sp)	/* 5 registers saved */
-	movem.l	24(%sp), %d1-%d6
+	/*
+	 * According to eglibc, separate moves are faster than movem;
+	 * speed is important and this code is not duplicated anyway,
+	 * so we do the same here. We use %a1 as scratch register for
+	 * saving; syscall arguments are to be in %d1 to %d5 and %a0.
+	 */
+	move.l	24(%sp), %a0		/* orig.sp+24: arg 6 */
+	move.l	%d5, -(%sp)		/* push d5 (callee saved) */
+	move.l	24(%sp), %d5		/* orig.sp+20: arg 5 */
+	move.l	%d4, -(%sp)		/* push d4 (callee saved) */
+	move.l	24(%sp), %d4		/* orig.sp+16: arg 4 */
+	move.l	%d3, -(%sp)		/* push d3 (callee saved) */
+	move.l	24(%sp), %d3		/* orig.sp+12: arg 3 */
+	move.l	%d2, %a1		/* save d2 (callee saved) in a1 */
+	move.l	20(%sp), %d2		/* orig.sp+8:  arg 2 */
+	move.l	16(%sp), %d1		/* orig.sp+4:  arg 1 */
 	trap	#0
-	cmpi.l	#-4095, %d0
-	blt.l	1f
+	move.l	%a1, %d2		/* restore d2 from a1 (scratch) */
+	move.l	(%sp)+, %d3		/* pop d3..d5, see above */
+	move.l	(%sp)+, %d4
+	move.l	(%sp)+, %d5
+
+	/* syscall is done, result in %d0, registers are restored */
+	.globl	__syscall_checkandout
+__syscall_checkandout:
+	/* now check for error */
+	cmp.l	#-4095, %d0
+	bcs.l	1f			/* jump if _not_ error */
+
+	/* prepare for error return */
 	neg.l	%d0
 	move.l	%d0, (errno)
-	moveq	#-1, %d0
-1:
-	movea.l	%d0, %a0	/* Redundant return */
-	movem.l (%sp)+, %d2-%d6 /* Restore registers */
+	move.l	#-1, %d0
+	/* fallthrough into common return path */
+
+1:	/* copy return value to %a0 for syscalls returning pointers */
+	move.l	%d0, %a0
 	rts
 
 	.size	__syscall_common,.-__syscall_common
diff --git a/usr/klibc/arch/m68k/vfork.S b/usr/klibc/arch/m68k/vfork.S
index a3a7e44..98170a6 100644
--- a/usr/klibc/arch/m68k/vfork.S
+++ b/usr/klibc/arch/m68k/vfork.S
@@ -15,14 +15,9 @@ vfork:
 	move.l	(%sp)+, %d1		/* Return address */
 	move.l	# __NR_vfork, %d0
 	trap	#0
-	move.l	%d1, -(%sp)
-	cmpi.l	#-4095, %d0
-	blt.l	1f
-	neg.l	%d0
-	move.l	%d0, (errno)
-	moveq	#-1, %d0
-1:
-	movea.l	%d0, %a0
-	rts
+	move.l	%d1, -(%sp)		/* restore stack */
+
+	/* fallthrough into common code from syscall.S */
+	bra	__syscall_checkandout
 
 	.size	vfork, .-vfork
diff --git a/usr/klibc/open.c b/usr/klibc/open.c
index 9b0897a..126f6db 100644
--- a/usr/klibc/open.c
+++ b/usr/klibc/open.c
@@ -10,7 +10,7 @@
 #include <fcntl.h>
 #include <bitsize.h>
 
-#if _BITSIZE == 32 && !defined(__i386__)
+#if _BITSIZE == 32 && !defined(__i386__) && !defined(__m68k__)
 
 extern int __open(const char *, int, mode_t);
 
diff --git a/usr/klibc/openat.c b/usr/klibc/openat.c
index 83c87cd..8e5baa0 100644
--- a/usr/klibc/openat.c
+++ b/usr/klibc/openat.c
@@ -10,7 +10,7 @@
 #include <fcntl.h>
 #include <bitsize.h>
 
-#if _BITSIZE == 32 && !defined(__i386__) && defined(__NR_openat)
+#if _BITSIZE == 32 && !defined(__i386__) && !defined(__m68k__) && defined(__NR_openat)
 
 extern int __openat(int, const char *, int, mode_t);
 
-- 
1.7.8.3

[PATCH 0/2 v3] mkstemp() and m68k support

[Thorsten Glaser]

Hi,

after a year, I decided to hack on klibc again. I’ve reworked
both the patch to add mkstemp(), discussing to use AT_RANDOM
as cheap entropy source on IRC (if there will ever be another
entropy consumer, I can quickly write a minimal arc4random()
seeded from it, as it has only 16 octets), capable of making
a working mksh (static and shared) on amd64/xen, and the m68k
support code, leading to (also, static and shared) mksh on it
iff compiled with -g (let’s say, GCC is the culprit).

The two patches _should_ follow (still not 100% sure how to
feed them to sendmail and ensure they end up with the right
recipients) and are independent from each other (but for an
mksh on m68k, you obviously need both).

Cc the Linux/m68k arch list for the m68k patch, to review.

(When this works I’m probably going to build mksh-static on
dietlibc-less Debian architectures against klibc, pending
testing on those platforms of course; the eglibc one is huge.)

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (242 (261) bugs: 0 RC, 169 (183) I&N, 73 (78) M&W, 0 F&P)
‣ src:dash (73 (84) bugs: 3 RC, 27 (30) I&N, 43 (51) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?

Re: [PATCH 0/2 v3] mkstemp() and m68k support

[Michael Schmitz]

Thorsten,
> after a year, I decided to hack on klibc again. I’ve reworked
> both the patch to add mkstemp(), discussing to use AT_RANDOM
> as cheap entropy source on IRC (if there will ever be another
> entropy consumer, I can quickly write a minimal arc4random()
> seeded from it, as it has only 16 octets), capable of making
> a working mksh (static and shared) on amd64/xen, and the m68k
> support code, leading to (also, static and shared) mksh on it
> iff compiled with -g (let’s say, GCC is the culprit).
>
> The two patches _should_ follow (still not 100% sure how to
> feed them to sendmail and ensure they end up with the right
You appear to have failed. Care to post it to your p.d.o page?

(I've never tried talking to sendmail directly except for low level 
testing - you'll have to manually prepare a valid mail message with the 
attachments embedded for that to work I guess. That's what mutt and 
friends are for)
> recipients) and are independent from each other (but for an
> mksh on m68k, you obviously need both).
>
> Cc the Linux/m68k arch list for the m68k patch, to review.
>
> (When this works I’m probably going to build mksh-static on
> dietlibc-less Debian architectures against klibc, pending
> testing on those platforms of course; the eglibc one is huge.)
Good luck with that.

Cheers,

   Michael

Re: [PATCH] fix m68k support

[Andreas Schwab]

Thorsten Glaser <tg@mirbsd.org> writes:

> +	bcs.l	1f			/* jump if _not_ error */

Why .l?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH 0/2 v3] mkstemp() and m68k support

[Geert Uytterhoeven]

On Sun, Jan 29, 2012 at 04:11, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>> The two patches _should_ follow (still not 100% sure how to
>> feed them to sendmail and ensure they end up with the right
>
> You appear to have failed. Care to post it to your p.d.o page?
>
> (I've never tried talking to sendmail directly except for low level testing
> - you'll have to manually prepare a valid mail message with the attachments
> embedded for that to work I guess. That's what mutt and friends are for)

git send-email [--to xxx] [--cc xxx] ... <file>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] fix m68k support

[Thorsten Glaser]

Andreas Schwab dixit:

>Thorsten Glaser <tg@mirbsd.org> writes:
>
>> +	bcs.l	1f			/* jump if _not_ error */
>
>Why .l?

Mostly copy/paste from other m68k asm code. I don’t know it
well enough to say, and I did the fix by mentally translating
this to i386 asm, fixing the logic bug there and translating
it back, plus peeking at eglibc… by all means, fix my bugs ;)

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Re: [PATCH 0/2 v3] mkstemp() and m68k support

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>On Sun, Jan 29, 2012 at 04:11, Michael Schmitz
><schmitzmic@googlemail.com> wrote:

>>> The two patches _should_ follow (still not 100% sure how to
>>> feed them to sendmail and ensure they end up with the right
>>
>> You appear to have failed. Care to post it to your p.d.o page?

Huh? I see them in the archives of the klibc list, and the one
for linux-m68k on GMane.

>git send-email [--to xxx] [--cc xxx] ... <file>

That’s assuming the box I send mail from is capable of
running git… (and doesn’t take care of In-Reply-To and
References headers, either).

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Re: [PATCH 0/2 v3] mkstemp() and m68k support

[Michael Schmitz]

Hi Thorsten,
>>> You appear to have failed. Care to post it to your p.d.o page?
> Huh? I see them in the archives of the klibc list, and the one
> for linux-m68k on GMane.
There were no attachments in my copy received via vger. If the patch is 
in the list archives somewhere, that's fine.

Cheers,

   Michael

Re: [PATCH 0/2 v3] mkstemp() and m68k support

[Thorsten Glaser]

Michael Schmitz dixit:

> There were no attachments in my copy received via vger. If the patch is in the
> list archives somewhere, that's fine.

The git people don’t want attachments. To me, attaching the
files generated by git format-patch to an explanatory mail
would be the natural thing to do, too – but…

I sent them as separate mails:
http://article.gmane.org/gmane.linux.ports.m68k/3398

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Re: [PATCH] fix m68k support

[Thorsten Glaser]

Dixi quod…

>- fix syscall API and vfork
>- support 6-argument syscalls
>- add open/openat special handling for non-regparm arches

For the archives, and to keep everyone in the loop (said
this on IRC already, in #klibc):

This patch is part of klibc (2.0~rc2-0.1) uploaded to Debian
unstable (which otherwise is git HEAD as of 11 Feb 2012).

I’ve built mksh against it (using an older mkstemp.c externally,
since the latest patch requires the libc_init.c change, which I
didn’t add to the Debian package) dynamically, and it worked.

Furthermore, I’ve built a minimal-ish sv4cpio archive (to be
passed as initrd) on m68k consisting of:
• klibc-utils
• that mksh binary
• a /init shell script to mount stuff and give a shell

ragnar76 successfully booted that (with the kernel image from
linux-image-3.2.0-1-atari_3.2.4-1_m68k.deb of proper Debian
unstable) on real hardware.

Andreas, if you would like a different jump instruction, feel
free to update my patch, as I bow to your superiour knowledge.
Otherwise I submit this as-is, tested.

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (246 (265) bugs: 1 RC, 172 (186) I&N, 73 (78) M&W, 0 F&P)
‣ src:dash (74 (85) bugs: 3 RC, 27 (30) I&N, 44 (52) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?