Description of problem: GDB does not "step" or "next" into the statements of an OpenMP parallel section. Version-Release number of selected component (if applicable): gdb-8.1-13.fc29.x86_64 It's likely that it affects some set of earlier versions too, though it's my understanding that this bug had been fixed at some point in the past. How reproducible: Compile test case as shown below and use GDB to debug it. Set breakpoint just prior to OMP parallel section and then attempt to "step" or "next" into it. Steps to Reproduce: 1. Compile testcase as follows: gfortran -fopenmp -g -O0 -o tpcommon_gfortran tpcommon.f 2. Use GDB to debug it: gdb tpcommon_gfortran 3. Set breakpoint at line 25, run, and then do "next" twice: break 25 run next next Actual results: [kev@rawhide-1 533176]$ gdb tpcommon_gfortran GNU gdb (GDB) Fedora 8.1-13.fc29 Copyright (C) 2018 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". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from tpcommon_gfortran...done. (gdb) break 25 Breakpoint 1 at 0x4009ac: file tpcommon.f, line 25. (gdb) run Starting program: /scratch/kev/533176/tpcommon_gfortran Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27.9000-13.fc29.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: Loadable section ".note.gnu.property" outside of ELF segments Breakpoint 1, correct () at tpcommon.f:25 25 N = 100 (gdb) next 26 !$omp parallel private(nthreads, iam, chunk) (gdb) next [New Thread 0x7ffff654e700 (LWP 1278)] [New Thread 0x7ffff5d4d700 (LWP 1279)] [New Thread 0x7ffff554c700 (LWP 1280)] 4 0 25 1 25 4 1 25 26 50 4 3 25 76 100 4 2 25 51 75 38 print * Expected results: The second "next" command should stop at line 29, e.g. something like this: 26 !$omp parallel private(nthreads, iam, chunk) (gdb) n [New Thread 0x7ffff654e700 (LWP 1294)] [New Thread 0x7ffff5d4d700 (LWP 1295)] [New Thread 0x7ffff554c700 (LWP 1296)] [Switching to Thread 0x7ffff5d4d700 (LWP 1295)] 29 nthreads = omp_get_num_threads() (I produced this output by placing a breakpoint on line 29 and then removing the indication that a breakpoint had been hit.) Additional info: This behavior is occurring because the compiler is placing the parallel region into an "outlined" internal function which it creates. In the tested release, GOMP_parallel (in libgomp) is being called. It creates the necessary threads and then invokes the outlined function. This is the stack trace for the master thread with a breakpoint placed at line 29: (gdb) bt #0 MAIN__._omp_fn.0 () at tpcommon.f:29 #1 0x00007ffff73ae093 in GOMP_parallel () from /lib64/libgomp.so.1 #2 0x00000000004009e8 in correct () at tpcommon.f:26 #3 0x0000000000400b96 in main (argc=1, argv=0x7fffffffdb53) at tpcommon.f:20 #4 0x00007ffff698d1eb in __libc_start_main () from /lib64/libc.so.6 #5 0x000000000040089a in _start () The non-master threads will have stack traces that look like this: (gdb) bt #0 MAIN__._omp_fn.0 () at tpcommon.f:29 #1 0x00007ffff73b6dae in gomp_thread_start () from /lib64/libgomp.so.1 #2 0x00007ffff6d305d4 in start_thread () from /lib64/libpthread.so.0 #3 0x00007ffff6a6414f in clone () from /lib64/libc.so.6 A proper fix will need to be able to skip through these intermediate functions / implementation details so that step or next lands on the correct source line. The work-around, for now, is to place a breakpoint within the parallel section and then either next or continue to the breakpoint.
(In reply to Kevin Buettner from comment #0) > it's my understanding that this bug had been fixed at some point in the past. Yes, the recent GDB regression due to a GCC change is described in Bug 1376201.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.