Bug 1376201 - Regression: Can't step or next into OMP parallel section
Summary: Regression: Can't step or next into OMP parallel section
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: gdb
Version: DTS 6.0 RHEL 7
Hardware: All
OS: Linux
Target Milestone: alpha
: 6.0
Assignee: Keith Seitz
QA Contact: Martin Cermak
Depends On: 533176 1564299
TreeView+ depends on / blocked
Reported: 2016-09-14 20:31 UTC by Jan Kratochvil
Modified: 2020-12-08 22:16 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 533176
Last Closed: 2020-12-08 22:16:00 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Sourceware 26851 0 P2 NEW Make next not skip over GOMP_parallel 2020-12-08 22:15:58 UTC

Description Jan Kratochvil 2016-09-14 20:31:16 UTC
+++ This bug was initially created as a clone of Bug #533176 +++

gdb.fortran/omp-step.exp: step into omp
FAIL: gcc-6.1.1-3.fc24.x86_64
PASS: gcc-4.8.5-4.el7.x86_64

This is currently a known regression due to recent GCC.
But it is a GDB bug.

!$omp parallel
  400a23:       48 8d 85 50 f0 ff ff    lea    -0xfb0(%rbp),%rax
  400a2a:       48 89 45 f0             mov    %rax,-0x10(%rbp)
  400a2e:       48 8d 45 f0             lea    -0x10(%rbp),%rax
  400a32:       b9 00 00 00 00          mov    $0x0,%ecx
  400a37:       ba 00 00 00 00          mov    $0x0,%edx
  400a3c:       48 89 c6                mov    %rax,%rsi
  400a3f:       bf 29 0b 40 00          mov    $0x400b29,%edi =<MAIN__._omp_fn.0>
  400a44:       e8 d7 fd ff ff          callq  400820 <GOMP_parallel@plt>

!$omp parallel
  400a8d:       48 8d 85 50 f0 ff ff    lea    -0xfb0(%rbp),%rax
  400a94:       48 89 45 f0             mov    %rax,-0x10(%rbp)
  400a98:       48 8d 45 f0             lea    -0x10(%rbp),%rax
  400a9c:       ba 00 00 00 00          mov    $0x0,%edx
  400aa1:       48 89 c6                mov    %rax,%rsi
  400aa4:       bf 9e 0b 40 00          mov    $0x400b9e,%edi
  400aa9:       e8 22 fe ff ff          callq  4008d0 <GOMP_parallel_start@plt>
  400aae:       48 8d 45 f0             lea    -0x10(%rbp),%rax
  400ab2:       48 89 c7                mov    %rax,%rdi
  400ab5:       e8 e4 00 00 00          callq  400b9e <MAIN__._omp_fn.0>
  400aba:       e8 d1 fd ff ff          callq  400890 <GOMP_parallel_end@plt>


GDB catches the step:
  stop_fn=(null) stopf=GOMP_parallel@plt
GDB would just need to extract the first parameter ($rdi) where to put a temporary breakpoint but gdbarch does not have first parameter register information.

Comment 1 Jan Kratochvil 2016-09-15 09:19:17 UTC
Not reassigning to GCC but just giving a Cc if you have an idea.

With older GCCs MAIN__ did call MAIN__._omp_fn.0 on its own.  With newer GCCs MAIN__ calls MAIN__._omp_fn.0 indirectly via GOMP_parallel().

For example a switch to the former calling method would be most easy for GDB but that is probably not going to happen.

Comment 2 Jakub Jelinek 2016-09-15 09:23:55 UTC
Yeah, that is not going to happen, it has been very much intentional.  And the main reason for that is that the former method is very much debugging unfriendly, it makes OMPD totally impossible among other things, because by the time other threads are used in the parallel, the initial thread already left the GOMP_parallel* calls and so finding anything about it from within libgomp is impossible.  All it knows that eventually the initial thread will call again another function from the library.

Comment 7 Red Hat Bugzilla Rules Engine 2018-06-30 19:18:37 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 8 Jan Kratochvil 2018-06-30 19:25:57 UTC
I did not want to close this Bug but there is no rhdts-9.0.0 flag for it.

Note You need to log in before you can comment on or make changes to this bug.