Subject: MIPS kernel emulator issues

From: Shantanu Gogate <[email-masked]>
Date: Wed, 29 Sep 2004 01:05:31 -0700 (PDT)

Guys,

Any pointers which will lead to explaining why I am getting segmentation fault and kernel
stacktraces on floating point instructions being generated through uClibc would be appreciated.

I found this thread involving Jeff and Jon a bit relevant to my problem. Hence mailing them
directly.
http://www.uclibc.org/lists/uclibc/2003-June/006379.html

This thread started by Jon is almost exactly my problem, but I dont see any replies to that post.
http://www.uclibc.org/lists/uclibc/2003-May/006182.html
Both these posts are over an year old.

The situation here is as follows:

I have 2 boards based on a 4Kc MIPS core. One on which we have
successfully ported everything from booloader to applications. The other
is almost similar to this one (the Processor core is the same), just the
things around like RAM,Flash chip, ENET PHY are different. We are using
cross compiler gcc (version 3.3.4) along with uClibc, kernel 2.4.25. Everything is working fine on
platform #1. The kernel as well as the userland applications are all compiled with the same gcc
cross compiler (version 3.3.4)

a) on platform #2 when I run any program which calls any function from
uClibc which uses floating point numbers you get a kernel stack trace
saying "Reserved instruction in kernel code in traps.c::do_ri, line 663"
and a lengthy stack trace follows.

b) the same static binary which just does z = x *y, where x,y,z are floats and prints two floating
point numbers runs fine on platform #1.

c) If I remove the "printf" and just write the floating point arithmetic
instructions ( i.e something like z = x*y ). I dont get the stack trace on platform #2 or #1

d) If I statically link this small program with glibc instead, it works
fine on platform #2 _and_ #1.

e) If I load the platform #2 with a kernel image over tftp from a remote machine
where the rootfs is embedded inside the kernel image itself, then the
dummy program linked with uClibc or glibc works fine ..no stacktrace !!!

If "e)" was not happening i.e the embedded ramdisk rootfs was also giving same
problems then one could have said that it was something to do with
incorrect compilation of uClibc itself, which is why it was working with
glibc but not with uClibc. However programs linked with the same uClibc
are working when the embedded rootfs kernel is loaded. How ?!? Why ?!! 

uClibc configuration is to have floating point support and "HAS_FPU=y". If I change "HAS_FPU=n"
then it does compile with "-msoft-float", however the printf output from the dummy program is just
"nan".

Regards,
Shantanu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com