From: Martin Rivers <rivers@lexmark.com>
To: gdb@sources.redhat.com
Subject: Debugging an OpenMP program with gcc4.2 and gdb 6.6
Date: Fri, 01 Jun 2007 13:14:00 -0000 [thread overview]
Message-ID: <46601BB3.5C95F7F3@lpdev.prtdev.lexmark.com> (raw)
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 );
}
next reply other threads:[~2007-06-01 13:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-01 13:14 Martin Rivers [this message]
2007-06-01 13:42 ` Daniel Jacobowitz
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=46601BB3.5C95F7F3@lpdev.prtdev.lexmark.com \
--to=rivers@lexmark.com \
--cc=gdb@sources.redhat.com \
/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