[Dwarf-Discuss] OpenMP back-traces

Chris Quenelle Chris.Quenelle at Sun.COM
Tue Jan 6 08:59:30 PST 2009

If the debugger wants to support nested parallel regions, 
then the relationship cannot be described statically
via PC locations.  Imagine your example if there are 
threads M and M2 which each have two helper threads.
M and M2 will be in the same function, at the same spot,
and you won't know which one owns which helper thread.

The Sun compiler provides a libmtsk_db library that 
can be used by a debugger at run time to query the 
parent/child relationships in a running process or 
core file.

The Sun compiler uses dwarf to describe the static 
relationship between an original function containing
a parallel region, and the "outlined" artificial
function that's created to contain the body of
the loop and be the starting location for the 
helper threads.

More details are here:


Andrew Cagney wrote:
> Hi,
> I've been looking at OpenMP and it appears to have a backtrace
> challenge similar to that of nested functions - conceptually the
> OpenMP threads result in a stack tree vis:
> <inner>
>     1          2
>     1          2
>      \          /
>       \       /
>          M
>          M
> <outer>
> Worker thread's 1 and 2 include closure information that let them
> refer to variables on the Main thread's stack.  This is typically
> implemented as disjoint threads vis:
>     M    1    2
>     M    1    2
>      *    *    *
>      *    *    *
> ("*" represents system stack information) and each thread contains
> some sort of thread chain pointer.  In such an implementation, the
> backtrace for thread 1 or 2 would include system frames and not the
> Main's stack as the user expects.  Has any one explored ways to
> describe the stack tree?  Perhaps something similar to
> DW_AT_static_link?
> Andrew
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

More information about the Dwarf-Discuss mailing list