gomp status

gomp status

[Hicham Mouline]

hello

What is the status of debugging parallel openmp regions with gdb?
In particular the ability to display thread-specific values of variables?

regards,

Re: gomp status

[Michael Snyder]

Hicham Mouline wrote:
> hello
> 
> What is the status of debugging parallel openmp regions with gdb?
> In particular the ability to display thread-specific values of variables?

I don't think this group has been particularly aware of that project.
It's new to me, I don't remember any discussion on gdb mailing lists.

Re: gomp status

[Jan Kratochvil]

On Fri, 27 Aug 2010 17:28:46 +0200, Hicham Mouline wrote:
> What is the status of debugging parallel openmp regions with gdb?
> In particular the ability to display thread-specific values of variables?

There is fix of OMP stepping:
http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/gdb-bz533176-fortran-omp-step.patch?content-type=text%2Fplain&view=co

and it worked some way during my tests.  But I cannot report on more details
offhand.  There is a generated new function for the parallel block which
should have debug info for all its local variables.


Regards,
Jan

RE: gomp status

[Hicham Mouline]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: 30 August 2010 18:58
> To: Hicham Mouline
> Cc: gdb@sourceware.org
> Subject: Re: gomp status
> 
> On Fri, 27 Aug 2010 17:28:46 +0200, Hicham Mouline wrote:
> > What is the status of debugging parallel openmp regions with gdb?
> > In particular the ability to display thread-specific values of
> variables?
> 
> There is fix of OMP stepping:
> http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/gdb-bz533176-
> fortran-omp-step.patch?content-type=text%2Fplain&view=co
> 
> and it worked some way during my tests.  But I cannot report on more
> details
> offhand.  There is a generated new function for the parallel block
> which
> should have debug info for all its local variables.
> 
> 
> Regards,
> Jan

I've used gdb 7.1.26 to debug a binary built with g++4.3.3 (C++) and the
libgomp that comes with it.
I can step in/over properly inside a parallel block but I can't
display/watch variables inside it.
It says "symbol unavailable" or something like that.
Variables just outside the // block are displayed fine,

Is the fix you mention above fortran-specific? Is it in 7.1.x?

regards,

Re: gomp status

[Jan Kratochvil]

On Tue, 31 Aug 2010 01:21:15 +0200, Hicham Mouline wrote:
> I've used gdb 7.1.26 to debug a binary built with g++4.3.3 (C++) and the
> libgomp that comes with it.
> but I can't display/watch variables inside it.  It says "symbol unavailable"
> or something like that.

You haven't provided a problem reproducer.  It works for me for example for:
	https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c

gcc (GCC) 4.5.2 20100830 (prerelease)
GNU gdb (GDB) 7.2.50.20100831-cvs
This GDB was configured as "x86_64-unknown-linux-gnu".
(gdb) b 27
Breakpoint 1 at 0x4006dc: file omp-hello.c, line 27.
(gdb) r
Breakpoint 1, main.omp_fn.0 (.omp_data_i=0x0) at omp-hello.c:27
27	  printf("Hello World from thread = %d\n", tid);
(gdb) p tid
$1 = 2
(gdb) c
Continuing.
[Switching to Thread 0x7ffff3ffc710 (LWP 19165)]
Breakpoint 1, main.omp_fn.0 (.omp_data_i=0x0) at omp-hello.c:27
27	  printf("Hello World from thread = %d\n", tid);
(gdb) p tid
$2 = 6
(gdb) bt
#0  main.omp_fn.0 (.omp_data_i=0x0) at omp-hello.c:27
#1  0x00007ffff7bd8062 in gomp_thread_start (xdata=<value optimized out>) at ../../../libgomp/team.c:115
#2  0x00007ffff79b9d5b in start_thread (arg=0x7ffff3ffc710) at pthread_create.c:301
#3  0x00007ffff76ff85d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) _


> > There is fix of OMP stepping:
> > http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/gdb-bz533176-fortran-omp-step.patch?content-type=text%2Fplain&view=co
> 
> I can step in/over properly inside a parallel block

With FSF GDB:
(gdb) start
[...]
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe028) at omp-hello.c:22
22	#pragma omp parallel private(nthreads, tid)
(gdb) next
[New Thread 0x7ffff7201710 (LWP 30723)]
[New Thread 0x7ffff6800710 (LWP 30730)]
[New Thread 0x7ffff5dff710 (LWP 30740)]
[New Thread 0x7ffff53fe710 (LWP 30741)]
[New Thread 0x7ffff49fd710 (LWP 30742)]
[New Thread 0x7ffff3ffc710 (LWP 30744)]
[New Thread 0x7ffff35fb710 (LWP 30748)]
Hello World from thread = 6
Hello World from thread = 7
Hello World from thread = 4
Hello World from thread = 2
Hello World from thread = 3
Hello World from thread = 1
Hello World from thread = 0
Number of threads = 8
Hello World from thread = 5
38	}
(gdb) 

With patched GDB (gdb-7.1.90.20100721-6.fc14.x86_64):
(gdb) start
[...]
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe028) at omp-hello.c:22
22	#pragma omp parallel private(nthreads, tid)
(gdb) next
[New Thread 0x7ffff7201710 (LWP 11368)]
[New Thread 0x7ffff6800710 (LWP 11369)]
[New Thread 0x7ffff5dff710 (LWP 11370)]
[New Thread 0x7ffff53fe710 (LWP 11371)]
[New Thread 0x7ffff49fd710 (LWP 11372)]
[New Thread 0x7ffff3ffc710 (LWP 11373)]
[New Thread 0x7ffff35fb710 (LWP 11374)]
Hello World from thread = 7
main.omp_fn.0 (.omp_data_i=0x0) at omp-hello.c:26
26	  tid = omp_get_thread_num();
(gdb) 


> Is the fix you mention above fortran-specific?

No.

> Is it in 7.1.x?

No, this is not in FSF GDB, it is only a hack, there should be some proper
DWARF annotation instead.


Regards,
Jan