linux-mips
[Top] [All Lists]

Problem running Mips2 user space code

To: linux-mips@linux-mips.org
Subject: Problem running Mips2 user space code
From: "Jon Burgess" <Jon_Burgess@eur.3com.com>
Date: Thu, 19 Sep 2002 16:40:05 +0100
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org

We have an product with an embedded Mips32 processor running CVS linux_2_4_17.
Everything seems to work well when we compile our user space code with the
default GCC options (i.e. producing mips1 code) but if we optimise the user
space code to use the same CPU flags as the kernel (-mips2 -mcpu=r4600) then
code crashes intermittently . Has anyone else tried running mips2 user mode
code?

Both the kernel and user space code are compiled with HJ Lu's toolchain 20020627
RPMs. This toolchain flags the binaries as 'mips2' so I had to copy the
include/asm/elf.h file from CVS HEAD to get them to execute. As far as I can
tell this should be OK. I can update the kernel to the latest CVS if required,
but I need to apply some board specific changes.

I have a developed a small (1kb source) test program which exhibits the problem.
This source build the executables 'mips1' & mips2'. When these are run the mips2
program iterates a few times but normally stops in a couple of seconds reporting
total=7, where as it should be 6. The mips1 program always gets the correct
answer and keeps on running. Does the same thing happen for anyone else?

I examined the instructions which are involved in causing the crashes and found
that it seems to be related to the use of the 'branch likely' instruction in the
Mips2 code, generated for the lines 'if (X) bar(X)' in the test program. The
same instructions run every loop iteration and it only occasionally gets the
wrong answer. The problem seems to be that the branch likely delay slot
instruction fails to get nullified even though the branch is not taken. Could a
task schedule or exception while executing the branch likely instruction cause a
problem?

I can send the compiled executable directly if anyone is interested in trying my
executables on another board/kernel (total about 16kb) -- just in case it is
caused by a toolchain problem. I just read Ralfs comment about not sending
files, tars or compressed files to the mailing list, hopefully he won't mind the
source.

     Jon

(See attached file: Makefile)(See attached file: bnel2.c)

Attachment: Makefile
Description: Binary data

Attachment: bnel2.c
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>