Subject: A new mips toolchain is available

From: "H . J . Lu" <[email-masked]>
Date: Mon, 11 Jun 2001 21:03:11 -0700

I put my new mips toolchain at

http://ftp.kernel.org/pub/linux/devel/binutils/mips/

There are source rpms for RedHat 7.1. They may only be built correctly
with rpm, especially binutils. I can provide mips and mipsel binaries
rpms for them. But it will take at least a few days.

BTW, my toolchain is for the SVR4 MIPS ABI. I don't know how compatible
it is with the IRIX ABI. Old IRIX ABI binaries seem to run fine. But I
don't know abour the IRIX ABI DSOs. Also my glibc is compiled with
-mmips2 since kernel cannot handle mips I glibc.

H.J.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 12 Jun 2001 13:39:25 +0200

On Mon, Jun 11, 2001 at 09:03:11PM -0700, H . J . Lu wrote:

> don't know abour the IRIX ABI DSOs.

No known issues except that modutils only works ok with SVR4 ABI flavoured
binaries.

> Also my glibc is compiled with -mmips2 since kernel cannot handle mips I
> glibc.

It's noticable faster also ...

  Ralf

---

From: "H . J . Lu" <[email-masked]>
Date: Tue, 12 Jun 2001 09:40:55 -0700

> No known issues except that modutils only works ok with SVR4 ABI flavoured

FYI, my glibc includes

        * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Commented out.

        * sysdeps/mips/rtld-ldscript.in: Removed.
        * sysdeps/mips/rtld-parms: Likewise.
        * sysdeps/mips/mips64/rtld-parms: Likewise.
        * sysdeps/mips/mipsel/rtld-parms: Likewise.

As I mentioned before, the resulting glibc works fine with the IRIX ABI
executables. But I have no ideas about DSOs.

H.J.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 12 Jun 2001 21:11:51 +0200

>         * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Commented out.

That means elf/dl-load.c will assume zero for the load address.  That will
crash static programs which expect a value of 0x5ffe0000 and are trying to
dlopen a shared library which uses a different value.  Most popular
example is rpm.  So we need to keep ``#define MAP_BASE_ADDR(l) 0x5ffe0000''
in there until we've got a real fix, unfortunately.

ABI requires us to properly support DT_MIPS_BASE_ADDRESS, so that needs
to fixed for real anyway ...

> executables. But I have no ideas about DSOs.

This rtld stuff was an IRIX-ism which made it into Linux without the necessary
reflection; nothing bad should happen if we remove it.

  Ralf

---

From: "H . J . Lu" <[email-masked]>
Date: Tue, 12 Jun 2001 12:38:43 -0700

> to fixed for real anyway ...

Please provide me some testcases. I will look into them.

H.J.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 13 Jun 2001 09:57:52 +0200 (MET DST)

> -mmips2 since kernel cannot handle mips I glibc.

 What's the problem with the kernel?  It works fine for my R3400A
DECstation.  Glibc is 2.2.3 as released.  If there is something wrong, I
definitely want to know. 

 Of course, you might want to run MIPS II binaries for performance
reasons, anyway. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: "H . J . Lu" <[email-masked]>
Date: Wed, 13 Jun 2001 08:08:29 -0700

> DECstation.  Glibc is 2.2.3 as released.  If there is something wrong, I

It has something to do with the atomic emulation in kernel for mips I.

H.J.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 13 Jun 2001 17:22:49 +0200 (MET DST)

> It has something to do with the atomic emulation in kernel for mips I.

 Hmm, I thought Florian's sysmips() fixes went in.  Here is a patch I use
successfully for some time.  It doesn't work for small negative integers,
but glibc doesn't use them, AFAIK.

 Another possibility is to use the set of two patches for
sys__test_and_set() I've sent here recently.  This would break portability
for now, though, if you wanted to distribute glibc or kernel binaries.
This is also the reason I didn't put my current patched version of glibc
on my FTP site.

 The patch is not against a current version of the kernel -- you might
need to apply it manually.

  Maciej

patch-mips-2.4.0-test11-20001211-sysmips-0
diff -up --recursive --new-file linux-mips-2.4.0-test11-20001211.macro/arch/mips/kernel/sysmips.c linux-mips-2.4.0-test11-20001211/arch/mips/kernel/sysmips.c
--- linux-mips-2.4.0-test11-20001211.macro/arch/mips/kernel/sysmips.c	Sat Nov 18 05:27:01 2000
+++ linux-mips-2.4.0-test11-20001211/arch/mips/kernel/sysmips.c	Tue Dec 12 23:09:57 2000
@@ -75,21 +75,31 @@ sys_sysmips(int cmd, int arg1, int arg2,
 	}
 
 	case MIPS_ATOMIC_SET: {
-		unsigned int tmp;
+		int tmp1;
 
 		p = (int *) arg1;
 		errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
 		if (errno)
 			return errno;
+
 		errno = 0;
 
+#ifndef CONFIG_CPU_HAS_LLSC
+
+		save_and_cli(tmp1);
+		errno |= __get_user(tmp, p);
+		errno |= __put_user(arg2, p);
+		restore_flags(tmp1);
+
+#else /* CONFIG_CPU_HAS_LLSC */
+
 		__asm__(".set\tpush\t\t\t# sysmips(MIPS_ATOMIC, ...)\n\t"
 			".set\tmips2\n\t"
 			".set\tnoat\n\t"
-			"1:\tll\t%0, %4\n\t"
-			"move\t$1, %3\n\t"
-			"2:\tsc\t$1, %1\n\t"
-			"beqz\t$1, 1b\n\t"
+			"1:\tll\t%0, %5\n\t"
+			"move\t%3, %4\n\t"
+			"2:\tsc\t%3, %1\n\t"
+			"beqz\t%3, 1b\n\t"
 			".set\tpop\n\t"
 			".section\t.fixup,\"ax\"\n"
 			"3:\tli\t%2, 1\t\t\t# error\n\t"
@@ -98,23 +108,17 @@ sys_sysmips(int cmd, int arg1, int arg2,
 			".word\t1b, 3b\n\t"
 			".word\t2b, 3b\n\t"
 			".previous\n\t"
-			: "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno)
+			: "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno),
+			  "=&r" (tmp1)
 			: "r" (arg2), "o" (* (u32 *) p), "2" (errno)
 			: "$1");
 
+#endif /* CONFIG_CPU_HAS_LLSC */
+
 		if (errno)
 			return -EFAULT;
 
-		/* We're skipping error handling etc.  */
-		if (current->ptrace & PT_TRACESYS)
-			syscall_trace();
-
-		__asm__ __volatile__(
-			"move\t$29, %0\n\t"
-			"j\tret_from_sys_call"
-			: /* No outputs */
-			: "r" (&cmd));
-		/* Unreached */
+		return tmp;
 	}
 
 	case MIPS_FIXADE:

---

From: "H . J . Lu" <[email-masked]>
Date: Wed, 13 Jun 2001 08:24:17 -0700

> need to apply it manually.

I don't have problem with 2.4.0-test11. It is the change in 2.4.3
which breaks glibc.

H.J.

---

From: "H . J . Lu" <[email-masked]>
Date: Wed, 13 Jun 2001 08:44:16 -0700

On Wed, Jun 13, 2001 at 05:39:08PM +0200, Maciej W. Rozycki wrote:
>  You mean someone changed sysmips() in an incompatible way?  Aaarghh... 

I don't remeber the detail, it is eithet kernel crash or glibc crash.
I switched to mips II for glibc as the result.

H.J.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 13 Jun 2001 17:39:08 +0200 (MET DST)

---

From: Jun Sun <[email-masked]>
Date: Wed, 13 Jun 2001 11:48:15 -0700

> I switched to mips II for glibc as the result.

The latest CVS tree removed MIPS_ATOMIC_SET for CPUs without ll/sc.  See the
diff below.

RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -r1.17 -r1.18
77a78
> #ifdef CONFIG_CPU_HAS_LLSC
120a122,124
> #else
>       printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n");
> #endif

However the log says:

date: 2001/04/08 13:24:27;  author: ralf;  state: Exp;  lines: +4 -0
Fix ll/sc emulation.  Extracted from Linux-VR tree by Harald.

It seems that the checkin is a mistake because apparently it is not what
linux-vr is doing.  They used to have a piece of code for CPUs without ll/sc. 
And recently they moved to ll/sc instruction emulation.

Ralf, the following patch includes the original vr code for MIPS_ATOMIC_SET,
no ll/sc case.  Although we all know it is buggy (for small negative set
values), it is still better than nothing.

Jun

diff -Nru sysmips.c.orig sysmips.c
--- sysmips.c.orig	Wed Jun 13 11:32:09 2001
+++ sysmips.c	Wed Jun 13 11:46:06 2001
@@ -120,7 +120,23 @@
 			: "r" (&cmd));
 		/* Unreached */
 #else
-	printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n");
+               /* this is handled in assembly now */
+               panic("Unexpected MIPS_ATOMIC_SET call in sys_sysmips()");
+#else
+               int flags;
+
+               /* without ll/sc, we have a broken code that kind of works */
+                /* This is broken in case of page faults and SMP ...
+                   Risc/OS fauls after maximum 20 tries with EAGAIN.  */
+                p = (int *) arg1;
+                retval = verify_area(VERIFY_WRITE, p, sizeof(*p));
+                if (retval)
+                        goto out;
+                save_and_cli(flags);
+                retval = *p;
+                *p = arg2;
+                restore_flags(flags);
+                goto out;
 #endif
 	}

---

From: Harald Koerfgen <[email-masked]>
Date: Wed, 13 Jun 2001 22:55:00 +0200

On Wednesday 13 June 2001 20:48, Jun Sun wrote:
> The latest CVS tree removed MIPS_ATOMIC_SET for CPUs without ll/sc.  See
> the diff below.

[diff snipped]

> linux-vr is doing.  They used to have a piece of code for CPUs without
> ll/sc. And recently they moved to ll/sc instruction emulation.

Well, you seem to have a different linux-vr tree than I do :-)

> Ralf, the following patch includes the original vr code for
> MIPS_ATOMIC_SET, no ll/sc case.  Although we all know it is buggy (for
> small negative set values), it is still better than nothing.

Anyway, the linux-vr source tree has a partially working ll/sc emulation, at 
least enough for glibc, and MIPS_ATOMIC_SET is not neccessarily needed.
In fact, MIPS_ATOMIC_SET has been removed from the vr tree.

Regards,
Harald

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 14 Jun 2001 12:26:58 +0200 (MET DST)

> In fact, MIPS_ATOMIC_SET has been removed from the vr tree.

 I suppose we may remove it, too, once we agree on a sane replacement.