A new mips toolchain is available

A new mips toolchain is available

[H . J . Lu]

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.

Re: A new mips toolchain is available

[Ralf Baechle]

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

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

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

Re: A new mips toolchain is available

[H . J . Lu]

On Tue, Jun 12, 2001 at 01:39:25PM +0200, Ralf Baechle wrote:
> On Mon, Jun 11, 2001 at 09:03:11PM -0700, H . J . Lu wrote:
> 
> > 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.
> 
> No known issues except that modutils only works ok with SVR4 ABI flavoured
> binaries.

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.

Re: A new mips toolchain is available

[Ralf Baechle]

On Tue, Jun 12, 2001 at 09:40:55AM -0700, H . J . Lu wrote:

> FYI, my glibc includes
> 
>         * 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 ...

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

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

Re: A new mips toolchain is available

[H . J . Lu]

On Tue, Jun 12, 2001 at 09:11:51PM +0200, Ralf Baechle wrote:
> On Tue, Jun 12, 2001 at 09:40:55AM -0700, H . J . Lu wrote:
> 
> > FYI, my glibc includes
> > 
> >         * 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 ...
> 

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


H.J.

Re: A new mips toolchain is available

[Maciej W. Rozycki]

On Mon, 11 Jun 2001, H . J . Lu wrote:

> don't know abour the IRIX ABI DSOs. Also my glibc is compiled with
> -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: macro@ds2.pg.gda.pl, PGP key available        +

Re: A new mips toolchain is available

[H . J . Lu]

On Wed, Jun 13, 2001 at 09:57:52AM +0200, Maciej W. Rozycki wrote:
> On Mon, 11 Jun 2001, H . J . Lu wrote:
> 
> > don't know abour the IRIX ABI DSOs. Also my glibc is compiled with
> > -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. 
> 

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


H.J.

Re: A new mips toolchain is available

[Maciej W. Rozycki]

On Wed, 13 Jun 2001, H . J . Lu wrote:

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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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:

Re: A new mips toolchain is available

[H . J . Lu]

On Wed, Jun 13, 2001 at 05:22:49PM +0200, Maciej W. Rozycki wrote:
> On Wed, 13 Jun 2001, H . J . Lu wrote:
> 
> > >  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. 
> > 
> > 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
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> patch-mips-2.4.0-test11-20001211-sysmips-0

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


H.J.

Re: A new mips toolchain is available

[Maciej W. Rozycki]

On Wed, 13 Jun 2001, H . J . Lu wrote:

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

 You mean someone changed sysmips() in an incompatible way?  Aaarghh... 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: A new mips toolchain is available

[H . J . Lu]

On Wed, Jun 13, 2001 at 05:39:08PM +0200, Maciej W. Rozycki wrote:
> On Wed, 13 Jun 2001, H . J . Lu wrote:
> 
> > I don't have problem with 2.4.0-test11. It is the change in 2.4.3
> > which breaks glibc.
> 
>  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.

Re: A new mips toolchain is available

[Jun Sun]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

"H . J . Lu" wrote:
> 
> On Wed, Jun 13, 2001 at 05:39:08PM +0200, Maciej W. Rozycki wrote:
> > On Wed, 13 Jun 2001, H . J . Lu wrote:
> >
> > > I don't have problem with 2.4.0-test11. It is the change in 2.4.3
> > > which breaks glibc.
> >
> >  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.

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

[-- Attachment #2: junk --]
[-- Type: text/plain, Size: 998 bytes --]

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
 	}
 

Re: A new mips toolchain is available

[Harald Koerfgen]

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]

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

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

Re: A new mips toolchain is available

[Maciej W. Rozycki]

On Wed, 13 Jun 2001, Harald Koerfgen wrote:

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

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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +