Below is some additional information about the work I've been doing.
It may be useful in understanding where I'm going with my libgomp
patch and other patches still to come...
I've been working on improvements to gdb, gcc, and libgomp which make
GDB able to better access variables in an OpenMP program. Access to
some variables was already possible even before starting my work. One
case which did not work is access to variables which are not used in
an OpenMP parallel region.
Consider this program:
void foo (int a1) {}
int
main (void)
{
static int s1 = -41;
int i1 = 11, i2;
for (i2 = 1; i2 <= 2; i2++)
{
int pass = i2;
#pragma omp parallel num_threads (2) firstprivate (i1)
{
foo (i1);
}
foo(pass);
}
foo (s1); foo (i2);
}
When using GDB, if a breakpoint is placed on the "foo (i1)" line, GDB
was unable to access variables `s1', `i2', or `pass' in either of the
two threads that are created.
I recently committed a patch to GCC which now allows GDB to access all
of these variables, but at the moment, GDB is only able to find stack
based variables (e.g. i2 and pass) for the master thread. Finding
static variables (e.g. s1) now works from any thread.
In order to find stack based variables from non-master thread(s), GDB
needs to be able to find the parent thread and then look for the
variables on the stack of the parent thread.
I've recently committed/pushed patches to GDB which map a thread
handle to one of GDB's internal thread identifiers. This work
also exposes the mapping functionality via GDB's Python interface.
I provide an example of how this might be used later on.
On the GDB side of things, I have two other patches.
The first one implements an interface for a python function which I've
named `thread_parent'. The idea here is that we implement
thread_parent in Python and that GDB then uses this implementation,
when appropriate, to locate a parent thread.
The second patch makes calls to the thread_parent to find the thread
to search for stack based variables which are not found on the stack
of the current thread under consideration.
I also have a patch to libgomp which adds pthread id and parent
fields to the gomp_thread struct. These fields make it possible
for a debugger to know which pthread_t identifier corresponds to
a particular gomp thread. It also makes it possible for the debugger
to discern the parent / child relationship among threads.
Using the above work, thread_parent can be implemented in Python
as follows:
def thr_parent (thr):
try:
h = gdb.parse_and_eval("gomp_tls_data->parent->pthread_id")
parent = gdb.selected_inferior().thread_from_thread_handle(h)
return parent
except:
return None
gdb.thread_parent = thr_parent
Note the ease with with the thread handle is obtained from libgomp.
GDB's expression evaluator (which relies on having accurate DWARF
info) is used to fetch the thread handle via this expression:
gomp_tls_data->parent->pthread_id
This is the very expression that one might use within libgomp to
access the thread handle of the parent. The master thread has a NULL
parent, so attempting to access pthread_id for NULL throws an
exception, causing None to be returned.
The file in which this python code resides is placed in one of the
standard locations for python plugins for GDB. It must follow the
naming conventions which will cause it to be loaded when the libgomp
shared object is loaded. For the current version of libgomp, the file
is named libgomp.so.1.0.0-gdb.py. I've been placing it within the
same directory as libgomp.so, which is just a symlink to
libgomp.so.1.0.0. This file may also be placed a location relative to
auto-load in GDB's installed data directory. Also, it is my
understanding that this script could be placed in a .debug_gdb_scripts
section of the libgomp shared library.
It is expected that some of this work will (still) prove useful when
an OMPD library is implemented for libgomp. Some of it will, of
course, have to be discarded, but in the interim, it will improve
GDB's capability for debugging OpenMP programs.
