In case of OpenMP, compilers generate encapsulates code present in
OpenMP construct to artificial functions. This is done to apply parallelism
to block of code. In context of these blocks, currently containing scope
variables are not accessible. This is due to new artificial function DIE being
in global scope.
As from user point of view, containing scope is same lexical scope, there
must be correct DIE hierarchy for artificial functions, which should be child
of containing scope.
Please consider below testcase.
1 #include <stdio.h> 2 #include <stdlib.h> 3 4 int global_var1; 5 int global_var2 = 99; 6 int foo(int n) { 7 int same_var = 5; 8 int other_var = 21; 9 int share = 9, priv, i; 10 global_var1 = 99; 11 12 if (n < 2) 13 return n; 14 else { 15 int same_var = rand() % 5; 16 int local_var = 31; 17 #pragma omp parallel for 18 for (i = 0; i < n; i++) { 19 share += i; // <-------------- (A) 20 } 21 return share; 22 } 23 } 24 25 int main() { 26 int n = 10; 27 printf("foo(%d) = %d\n", n, foo(n)); 28 return 0; 29 }
Please consider the line# 19, user expects variables "same_var", "local_var", "other_var" to be
accessible inside debugger but which is not possible.
(gdb) p same_var No symbol "same_var" in current context. (gdb) p other_var No symbol "other_var" in current context. (gdb) p local_var No symbol "local_var" in current context.
After current patch.
(gdb) thr 1 [Switching to thread 1 (Thread 0x7ffff7c1c400 (LWP 17992))] #0 .omp_outlined._debug__ (.global_tid.=0x7fffffffdad0, .bound_tid.=0x7fffffffdac8, n=@0x7fffffffdf18: 10, share=@0x7fffffffdf0c: 9) at 1.c:19 19 share += i; (gdb) p same_var $1 = 3 (gdb) p local_var $2 = 31 (gdb) p other_var $3 = 21
In case of compiling optimized code with inlining enabled, the Scope may be either a scope of an inlined instance (which may appear multiple times), an abstract scope or a concrete out-of-line scope. All of them will match a single ScopeNode, so this will override the map's value multiple times and getDIE() will likely return something that one may not expect.
I've been working on patches that make possible for local types, imports and static variables to be scoped in a lexical block, see D125693 for backend-related changes. May be you could find something useful there (see DwarfCompileUnit::getOrCreateLexicalBlockDIE() and DwarfCompileUnit::getOrCreateContextDIE()) or could help to review the patches.