0

I have an issue with the OpenMP implementation "GOMP" (namely GNU OpenMP), running on a Microblaze processor. The MicroBlaze processor is in the kernel mainline, and Xilinx provided pthread implementation for it. So I cross-compiled the GOMP library starting from pthread implementation and inserted in the Linux kernel running on Microblaze (that is a 3.10 version, named Petalinux). Specifically, the problem is highlighted running one of the Parsec benchmarks (here is the link (http://parsec.cs.princeton.edu/download.htm)), namely blackscholes. The code section that shows problem is the following:

int bs_thread(void *tid_ptr) {
    int i, j;
    fptype price;
    fptype priceDelta;
    int tid = *(int *)tid_ptr;

    for (j=0; j<NUM_RUNS; j++) { 
#pragma omp parallel for private(i, price, priceDelta)
        for (i=0; i<numOptions; i++) {

            price = BlkSchlsEqEuroNoDiv( sptprice[i], strike[i],rate[i], volatility[i], otime[i], otype[i], 0);
            prices[i] = price;
            } 
    } 

return 0;

}

blackscholes can be launched with different input sets, and different thread numbers, with the command: blackscholes _num_threads_ _input_file_ _output_file_

Launching it with 1, 2, 3, 5, 7 threads and so on, following odd numbers, it works good. Launching it with 4, 6, 8, 10 threads and so on, following even numbers, it blocks. Again, by reducing the constant NUM_RUNS to 1, the application works good. My question is: is it possible that the GOMP implementation suffers of worksharing construct insertion (namely omp parallel for) after a for cycle?

Thank you.

GiacAlkal
  • 1
  • Have you tried debugging it? Where the threads hang would give you a good insight... Unfortunately it is unlikely that we can help you significantly given that we can hardly reproduce it and it is likely some bug within in huge amounts of code (e.g. libgomp). – Zulan Jun 01 '17 at 11:45
  • Hi, the main problem comes from the fact that, talking about debugging phase as related to GDB, I can't do it. This is because, after the cross-compilation action of GDB, I should use it via UART controller. The MicroBlaze is giving a lot of problems using GDB via UART, and it works good only with Ethernet line. I can't put an Ethernet controller on my system "so fast", so I am trying to analyze the problem using other tools. Do you have some suggestion on what other kinds of debugger can I use? For example, I built strace successfully. – GiacAlkal Jun 01 '17 at 18:17
  • How about forcing a core file? perf also might help. – Zulan Jun 01 '17 at 18:49
  • Thanks for the suggestion, I am working on forcing a core file dump. Actually I was able to configure the kernel to generate it and, after the stop of the block of the program, I was able to generate the core file using the "kill -ABRT _pid_" command. I am now working on analyzing this dump file using gdb on the host. I'll post updates. – GiacAlkal Jun 02 '17 at 17:36

0 Answers0