Problem running Mips2 user space code

Problem running Mips2 user space code

[Jon Burgess]

[-- 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;
}

Re: Problem running Mips2 user space code

[Ralf Baechle]

On Thu, Sep 19, 2002 at 04:40:05PM +0100, Jon Burgess wrote:

> 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.

The comment was refering to patches sent to me.  Having to unzip and untar
patch sets is just a waste of time.  The easiest thing to deal with my is
one inline patch per email, no attachments.  For those pour souls that use
mails that garble patches (Some Pine versions, Netscape, Mozilla, Lotus
Notes, MS stuff) one patch attached per mail.

  Ralf

Re: Problem running Mips2 user space code

[Jon Burgess]

I just enabled the DEBUG_CACHE in mm/c-mips32.c and the program fails
immeadiately after some cache routines have been called. We have already seen a
cache related problem with this chip so it looks like be caused by a hardware
problem not the kernel. Sorry to trouble you all with this. I'll be in touch
again if it looks like a kernel problem.

Thanks,
     Jon