openblasgem5

gem5 syscall emulation OpenBLAS cblas_dgemm fails with "fatal: syscall mbind (#237) unimplemented"


I am working on a program that I need to simulate program that called OpenBLAS functions with gem5 in SE mode. My code(in C) is as below

#include <cblas.h>
#include <stdio.h>

void main()
{
  int i=0;
  double A[6] = {1.0,2.0,1.0,-3.0,4.0,-1.0};
  double B[6] = {1.0,2.0,1.0,-3.0,4.0,-1.0};
  double C[9] = {.5,.5,.5,.5,.5,.5,.5,.5,.5};
  cblas_dgemm(CblasColMajor, CblasNoTrans, CblasTrans,3,3,2,1,A, 3, B, 3,2,C,3);

  for(i=0; i<9; i++)
    printf("%lf ", C[i]);
  printf("\n");
  printf("hello hihi\n");
}

which is an example from OpenBLAS. I am pretty sure I have statically compiled this file with following makefile command

test_cblas_dgemm: test_cblas_dgemm.c
        @echo compiling $@
        @gcc -static -I $(INCLUDE) -L.  $< -o test_cblas_dgemm -lopenblas
        @cp test_cblas_dgemm ~/progs/

The problem is that I can run the executable file on my ubuntu machine but it meet with fatal errors on the gem5 SE mode. The simulation output is like below

**** REAL SIMULATION ****
info: Entering event queue @ 0.  Starting simulation...
warn: readlink() called on '/proc/self/exe' may yield unexpected results in various settings.
      Returning '/home/hurui/progs/test_cblas_dgemm'
info: Increasing stack size by one page.
warn: ignoring syscall access(...)
fatal: syscall mbind (#237) unimplemented.
Memory Usage: 648616 KBytes

Anybody can help me out? Thanks.


Solution

  • I believe that you cannot overcome this error without patching gem5, since in SE mode, every syscall must be explicitly implemented, as can be guessed form the source code:

    src/arch/arm/linux/process.cc:443:    /* 319 */ SyscallDesc("mbind", unimplementedFunc),                 
    

    As an alternative, can't you run that in a full system simulation instead? For example, I got it working very easily using this Buildroot setup running your exact same test program.

    FS tends to be much simpler to port things to, as the system is more realistic and there are less restrictions on what you can do.

    Another alternative would be to patch BLAS to remove the syscall, but you likely don't want to do that, as it would make your run less representative and likely just uncover further failures.

    Please write to the mailing list as well to confirm what I've told you.