Linux MIPS Architecture development
 help / color / mirror / Atom feed
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;
}



             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