Hide Forgot
+++ 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.
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.
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.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
I did not want to close this Bug but there is no rhdts-9.0.0 flag for it.