This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Debugging an OpenMP program with gcc4.2 and gdb 6.6


My system is a RedHat Enterprise Linux 3 system.  I've built a native gcc 4.2.0
compiler and am using binutils 2.17.50 as well as gdb 6.6.  In trying to learn
about OpenMP, I created what I believed to be a very trivial program below.  I
then attempted to set a breakpoint at the 'num threads %d' printf (line 15).  I
then ran the program.  The breakpoint was hit but when doing a 'next' command,
control returns to the top of main (line 4).  Entering another "next" command
results in control returning to line 15 (the 'num threads' printf).  However,
before that break at line 15 is hit, I get the results two 'num threads' strings

displayed to the console.  Finally, entering the 'next' command again places
control at the #pragma omp barrier line (no printfs).

Thus I never actually seem to hit the breakpoint at the printf line in the
context of each thread to see it do the printf (the printfs occur, I just don't
see what I would consider appropriate breakpoint/next run control.

I then re-ran the program and this time set breakpoints at line 9 (x=5) and line

12 (sleep) and line 18 (if clause).  The first breakpoint I hit is line 15.
Entering 'continue' command hits the breakpoint at line 12 (sleep).  Entering
the 'continue' command again causes the breakpoint at line 9 to get hit.
Entering 'continue' yet again lands me at line 18.  Again, I do see appropriate
breakpoints in the context of each thread for lines 9 and 12 but never see
breakpoints for the printf (line 15) for the two threads.

My compile line is:

gcc42 -fopenmp -O0 -g -pthread -o try try.c


I admit I'm new to openmp but the above run control during the debug sessions
above don't seem right.  Is this what is expected?  Am I missing some gdb
patch?  Am I missing some other special debugging option?

This would not have been what I would have expected if I'd used pthreads
directly (I realize that there would be some amount of reordering of the program

below to use with pthreads).



#include <stdio.h>
#include <omp.h>
int main()
{
   int x = 2;
   #pragma omp parallel num_threads(2) shared(x)
   {
      if( omp_get_thread_num() == 0 )
         x = 5;
      else
      {
         sleep(1);
         printf( "1: Thread# %d: x=%d\n", omp_get_thread_num(), x );
      }
      printf( "num threads %d\n", omp_get_num_threads() );
   }
   #pragma omp barrier
   if( omp_get_thread_num() == 0 )
   {
      sleep(1);
      printf( "2: thread # %d: x = %d\n", omp_get_thread_num(), x );
   }
   else
   {
      printf( "3: thread # %d: x = %d\n", omp_get_thread_num(), x );
   }
   return( 0 );
}




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]