Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1376201

Summary: Regression: Can't step or next into OMP parallel section
Product: Red Hat Developer Toolset Reporter: Jan Kratochvil <jan.kratochvil>
Component: gdbAssignee: Keith Seitz <keiths>
Status: CLOSED UPSTREAM QA Contact: Martin Cermak <mcermak>
Severity: medium Docs Contact:
Priority: medium    
Version: DTS 6.0 RHEL 7CC: dsmith, ebachalo, jakub, jan.kratochvil, kbaxley, keiths, kevinb, law, mcermak, mnewsome, mpolacek, palves, qe-baseos-tools-bugs, tao
Target Milestone: alphaKeywords: Reopened
Target Release: 6.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 533176 Environment:
Last Closed: 2020-12-08 22:16:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 533176, 1564299    
Bug Blocks:    

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.

FAIL:
!$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>

PASS:
!$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>

http://pkgs.fedoraproject.org/cgit/rpms/gdb.git/tree/gdb-bz533176-fortran-omp-step.patch

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.