[Dwarf-Discuss] OpenMP back-traces
Chris Quenelle
Chris.Quenelle@Sun.COM
Tue Jan 6 16:59:30 GMT 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:
http://mediacast.sun.com/users/Chris_Quenelle/media/Sun_Dwarf2_Extensions.txt
--chris
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