Subject: Re: Floating point support

From: Philip Blundell <[email-masked]>
Date: Fri, 01 Jan 1999 19:13:40 +0100

>   Compiled with: arm-linux-gcc -o fp fp.cpp -static

Why are you using static binaries?  This is never a good idea except in very 
special cases.

Anyway, it seems that there is some bug that stops your program working with 
-static.  I tried it on both the Acorn emulator under 2.0 and NWFPE under 2.1 
and the results were the same.  Without -static it worked as expected with 
both versions.  I'd be surprised if the emulator was at fault; the bug is 
probably in the C runtime somewhere.

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Mark van Doesburg <[email-masked]>
Date: Fri, 1 Jan 1999 19:56:05 +0100

If you apply the kernel patch I mentioned here a few days ago
	you can build floating point emulation into the kernel.
	Otherwise there is a link to an old version of libfloat on my
	web page; I keep meaning to make a newer one including Scott's
	changes but I haven't had time yet.

I've applied the patch and compiled a new kernel. The new kernel is able
to run floating point SW but the result of the FP operations are
incorrect. In the case of a division the binary exits (i guess with a
division by zero) prematurely. (Test case appended)

I was unable to download libfloat, the link was not working.

Thanks,

Mark.

-------------------------------

/* The followin test case produces a zero for the first number printed
   with a + and -. When a / is used the result is not printed.
   When a * is used the result is incorrect 1->-0.25, 2->-2, 3->-6 ...

 */
#include <stdio.h>
#include <stdlib.h>

main(int argc,char **argv)
{
	double d=atof(argv[1]);
	printf("result %lf %lf\n",d+3,d);
}
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Fri, 1 Jan 1999 22:58:33 -0500 (EST)

> Why are you using static binaries?  This is never a good idea except in very 

No kidding!  
My special case is that I have only about 500 kb for all application
binaries in my system.  So it turns to be a single statically linked 
binary since dynamic libraries, even stripped, are much too big.

> probably in the C runtime somewhere.

Already got wrong fp results too, but didn't care since I had more
important bugs to cure...  May -static screw up threads too?  

Nicolas Pitre, B. ing.
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sat, 02 Jan 1999 13:18:33 +0100

>important bugs to cure...  May -static screw up threads too?  

It's certainly possible.  I don't know for a fact that there are problems but 
threads are one of the areas I'd be most wary about where static binaries are 
involved.

If you have trouble then let me know and I'll see what I can do.

p.

---

From: Nicolas Pitre <[email-masked]>
Date: Sat, 2 Jan 1999 12:55:52 -0500 (EST)

> If you have trouble then let me know and I'll see what I can do.

For sure I do!  :-(

Nicolas Pitre, B. ing.
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sat, 02 Jan 1999 23:27:34 +0100

>For sure I do!  :-(

You'll need to give more details of what you're trying to do and what exactly 
goes wrong.  I just built `ex1' from LinuxThreads static and it runs without 
any problems.  Does this work for you?

BTW, have you checked that threads actually work with your kernel?  I 
discovered the other day that they've apparently been broken in 2.1/ARM for 
some time and maybe 2.0 has the same problem (the NetWinder version seems 
OK but Corel may have fixed it off their own bat).  I've appended here the 
patch (for copy_thread() in arch/arm/process.c) that I sent to Russell to 
fix it.

p.

--- clean/linux/arch/arm/kernel/process.c	Mon Dec 28 13:53:28 1998
+++ linux/arch/arm/kernel/process.c	Fri Jan  1 18:24:08 1999
@@ -169,6 +171,7 @@
 	childregs = ((struct pt_regs *)((unsigned long)p + 8192)) - 1;
 	*childregs = *regs;
 	childregs->ARM_r0 = 0;
+	childregs->ARM_sp = esp;
 
 	save = ((struct context_save_struct *)(childregs)) - 1;
 	copy_thread_css(save);

---

From: Nicolas Pitre <[email-masked]>
Date: Sat, 2 Jan 1999 22:20:41 -0500 (EST)

> any problems.  Does this work for you?

I'll be able to test it on Monday.  My problem is that execution never
gets out of pthread_create() nor a thread is started.  I started to trace
glibc v.106 and something hangs in thread_manager() or similar.  I'll get
more details on Monday too.

> OK but Corel may have fixed it off their own bat).
[..]

Yes, I found this one and fixed it in my kernel already.

Nicolas Pitre, B. ing.
[email-masked]

---

From: [email-masked]
Date: Sun, 03 Jan 1999 15:29:30 +0100

>more details on Monday too.

OK.  If you can strace the failing process that would be very helpful.  Also 
if you mail me your binary I can see if it works on another machine.  (The 
gnu.org mail server seems to be experiencing some downtime, so use this 
address rather than my usual one.)

p.

---

From: Nicolas Pitre <[email-masked]>
Date: Mon, 4 Jan 1999 21:05:13 -0500 (EST)

> address rather than my usual one.)

OK.  Finally found it.  It seems that threads can't work if they are
started from a process which PID is 1.  At some point in pthread_manager()
there is a test to see if getppid() returns 1 and if so, all threads are
killed because the main thread would have died.  In my case, the main
thread isn't dead but rather init itself.  Kind of subtile...

Don't know if it should be considered as a bug, but at least noted
somewhere as a limitation.

Thanks for your help!

P.S.: Don't know if I missed it, but what's needed to make floating point
work correctly with statically linked binaries?

Nicolas Pitre, B. ing.
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 06 Jan 1999 15:04:48 +0100

>work correctly with statically linked binaries?

I don't know.  Nobody has debugged it yet.

p.