From: "Jon Burgess" <Jon_Burgess@eur.3com.com>
To: linux-mips@linux-mips.org
Subject: Problem running Mips2 user space code
Date: Thu, 19 Sep 2002 16:40:05 +0100 [thread overview]
Message-ID: <80256C39.0056AAAC.00@notesmta.eur.3com.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
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 #2: Makefile --]
[-- Type: application/octet-stream, Size: 687 bytes --]
CROSS_COMPILE := /export/tools/bin/mips-linux-
AS := $(CROSS_COMPILE)as
LD := $(CROSS_COMPILE)ld
CC := $(CROSS_COMPILE)gcc
CPP := $(CC) -E
AR := $(CROSS_COMPILE)ar
NM := $(CROSS_COMPILE)nm
STRIP := $(CROSS_COMPILE)strip
OBJCOPY := $(CROSS_COMPILE)objcopy
OBJDUMP := $(CROSS_COMPILE)objdump
CFLAGS += -pipe -O -Wall
all: mips1 mips2
@#cp -f mips1 mips2 /tftpboot/161.71.54.23/sbin/
@#/export/tools/bin/mips-linux-objdump -d -mmips:isa32 mips2
mips1: bnel2.c
$(CC) $(CFLAGS) -o $@ $<
mips2: bnel2.c
$(CC) $(CFLAGS) -mcpu=r4600 -mips2 -o $@ $<
clean:
rm -f mips1 mips2
[-- Attachment #3: bnel2.c --]
[-- Type: application/octet-stream, Size: 1049 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>
typedef struct {
char spacer[0x28];
int p;
char spacer2[40];
int r;
char message[2100];
int q;
} s_test;
int total;
void start_child()
{
int pid = fork();
/* Parent */
if (pid)
return;
/* Child */
while(1)
{
sleep(1);
system("ls -l");
}
}
void bar(int x)
{
printf("Variable is %d\n", x);
total += x;
}
void foo(s_test *a)
{
printf("p = %d\n", a->p);
printf("q = %d\n", a->q);
printf("r = %d\n", a->r);
printf("Message is %s\n", a->message);
if (a->p)
bar(a->p);
if (a->q)
bar(a->q);
if (a->r)
bar(a->r);
}
int main(int argc, char *argv[])
{
char *string = "Hello world";
s_test data;
data.p=1;
data.q=2;
data.r=3;
strcpy(data.message, string);
start_child();
while(1)
{
total = 0;
foo(&data);
printf("Total %d\n", total);
if (total != 6)
break;
}
kill(0, SIGHUP);
return 0;
}
next reply other threads:[~2002-09-19 15:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-19 15:40 Jon Burgess [this message]
2002-09-20 0:47 ` Problem running Mips2 user space code Ralf Baechle
-- strict thread matches above, loose matches on Subject: below --
2002-09-19 16:41 Jon Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80256C39.0056AAAC.00@notesmta.eur.3com.com \
--to=jon_burgess@eur.3com.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox