Bug 533176

Event posted on 11-04-2009 06:04pm EST by woodard

[ben@quince common-block]$ gfortran44 -fopenmp    -g -O0 -o tpcommon_gfortran44 tpcommon.f
[ben@quince common-block]$ gdb ./tpcommon_gfortran44 
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) b 25
Breakpoint 1 at 0x4009b7: file tpcommon.f, line 25.
(gdb) r
Starting program: /home/ben/Work/TV-bugs/common-block/tpcommon_gfortran44 
[Thread debugging using libthread_db enabled]
[New Thread 0x2b733ab3f950 (LWP 18781)]

Breakpoint 1, correct () at tpcommon.f:25
25            N = 100
(gdb) n
26      !$omp parallel private(nthreads, iam, chunk)
(gdb) n
[New Thread 0x42584940 (LWP 18786)]
           2           1          50          51         100
           2           0          50           1          50
38            print *
(gdb) 

notice how it skips right over the parallel section rather than going into the parallel section. I believe that this has to do with the fact that the parallel section is treated like a function call by the compiler and consequently the debugger thinks that the next line is line 38 rather than 29. However, the local tools team asserts that gdb should be smart enough to make the experience of debugging parallel OpenMP code seamless. Therefore the temporary breakpoint that gdb should set to go to the next line in the source code line 29 rather than skipping over the parallel section.

This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 362141

Event posted on 11-04-2009 06:07pm EST by woodard

Totalview also stumbles over this problem.


This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 362141

Created attachment 367615 [details]
reproducer

Created attachment 367858 [details]
Patch using ".omp_fn." for gdb-6.8-38.el5.

I find it a bug in DWARF and gdb behaves correctly according to it.  From the current DWARF's point of view the is a function call which you skip by "next".

If you hide any /usr/lib/debug such as using:
gdb -nx -ex 'set debug-file-directory /qwe' -ex 'file ./tpcommon_gfortran44'
and use "step" command instead of "next" there it will work.
(You need to hide debuginfo from libgomp as you would step into libgomp sources to maintain the threads for execution.)

There should be some DWARF extension for it, currently tried to detect substring ".omp_fn." as this function is called "MAIN__.omp_fn.0" and do not consider such sub-function as a skippable by "next".

Another problem is that with "set scheduler-locking" being "off" (default upstream) or "step" (default in F/RHEL) the simultaneous execution of the threads is inconvenient.  Setting it to "on" will lockup the debugging as the threads need to get synchronized at some point.  This is a more general debugging problem of GOMP outside of the scope of this Bug.


(gdb) b 25
Breakpoint 1 at 0x4009cf: file tpcommon.f, line 25.
(gdb) run
Starting program: /home/jkratoch/t/tpcommon_gfortranold 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fb6492b7760 (LWP 29944)]

Breakpoint 1, correct () at tpcommon.f:25
25	      N = 100
(gdb) next
26	!$omp parallel private(nthreads, iam, chunk)
(gdb) next
[New Thread 0x7fb6492b6910 (LWP 29947)]
[New Thread 0x7fb6488b5910 (LWP 29948)]
[New Thread 0x7fb647eb4910 (LWP 29949)]
[New Thread 0x7fb6474b3910 (LWP 29950)]
[New Thread 0x7fb646ab2910 (LWP 29951)]
[New Thread 0x7fb6460b1910 (LWP 29952)]
[New Thread 0x7fb6456b0910 (LWP 29953)]
MAIN__.omp_fn.0 (.omp_data_i=0x7fffb22ff030) at tpcommon.f:29
29	      nthreads = omp_get_num_threads()
(gdb) next
30	      iam = omp_get_thread_num()
(gdb) next
31	      chunk = (N + nthreads - 1)/nthreads
(gdb) next
32	      istart = iam * chunk + 1
(gdb) next
33	      iend = min((iam + 1) * chunk, N)
(gdb) next
34	      print *, nthreads, iam, chunk, istart, iend
(gdb) next
           8           5          13          66          78
           8           1          13          14          26
           8           6          13          79          91
           8           0          13           1          13
           8           7          13          92         100
           8           3          13          40          52
           8           2          13          27          39
           8           4          13          53          65
36	      call work(iarray)
(gdb) next
26	!$omp parallel private(nthreads, iam, chunk)
(gdb) next
correct () at tpcommon.f:38
38	      print *
(gdb)

Created attachment 367859 [details]
Patch using ".omp_fn." for FSF GDB HEAD.

Fixed in gdb-7.0-13.el5.

Testcase: gdb.fortran/omp-step.exp

~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0285.html