Hi! I appreciate you are interested in this GSoC topic!
On Tue, Mar 24, 2020 at 09:18:50PM -0400, y2s1982 . via Gcc wrote: > > The OMPD project idea might be the most ambitious from the whole lot. > > Basically, the goal is to come up with a prototype implementation of > > chapter 5 of OpenMP 5.0 Specification > > (https://www.openmp.org/specifications/), so that OpenMP programs > > compiled with GCC can be debugged in GDB using OpenMP terminology. > > > > This is music to my ears. I am eagerly reading up on the documentation, > starting from their section 5 that seems to cover OMPD in detail. Yeah, we are looking for the header file and a new shared library that GDB or other debuggers will be able to dlopen and that will implement the OMPD APIs. That shared library will need to closely cooperate with the libgomp runtime library (should have sources in the libgomp/ subdirectory and built from its makefiles too), to agree on various details, like structure offsets etc. One possible way to implement it is just require that the OMPD library and libgomp library come from the exact same source tree and same architecture, perhaps using some hash or version number to verify it, another one is to add some read-only data to the libgomp shared library which would contain some version number and sizeof/offsetof values for whatever the OMPD library will need, where we could bump the version number if significant internal changes are done to the libgomp library which would make OMPD incompatible and the rest caught by the other values, or it could use something like https://infinitynotes.org/wiki/Infinity where libgomp would describe what OMPD needs to know and OMPD library parse that. The more independent the OMPD library is from the exact libgomp version, it will be easier for users but more work. Having it more independent will e.g. allow a 64-bit debugger to dlopen 64-bit libgompd (or whatever the library will be called) and debug not just 64-bit processes using OpenMP, but also 32-bit ones. Infinity notes certainly aren't a requirement and one could add that later, while expressing whatever the library needs to know in some other form. > > In order to start you need to understand how OpenMP programs are > > internally structured (compile some a few basic ones with > > -fdump-tree-optimized and then examine the generated dump) and > > especially familiarize yourself with the libgomp library that provides > > essential run-time support to OpenMP programs. Libgomp is part of GCC > > project, see https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgomp. > > > > Okay, I will try that. I guess I will try out some simple for loop and > see. Any particular sections or tips on reading the dump? There are several dumps that are useful for understanding what's going on. I'd recommend ... -fopenmp -fdump-tree-{gimple,omplower,ompexp,optimized}. All the dumps are GIMPLE (the first two in high GIMPLE and last two in low GIMPLE), which is GCC internal representation, but is quite close to C; it uses SSA form, SSA names have versions with underscore and version number appended to them (if it is just _123, then it is anonymous SSA name and early in the function it has some declared type). The gimple dump is the closest to the original source code, and is useful to find out e.g. what OpenMP clauses have been there explicitly and what have been added implicitly, omplower still has those clauses but already has the data sharing and mapping clauses expanded to some code which passes the values between the regions, adds privatized versions of the variables, etc. The ompexp pass then lowers the rest of the OpenMP constructs to actual IL statements, outlines parallel/task/target regions, adds library API calls etc. And optimized dump is at the end of the GIMPLE optimization pipeline, after many other optimizations. OMPD will primarily describe the runtime library, so what you care most is what API calls (usually GOMP_* functions) are called for the different constructs and how it is implemented on the library side. Jakub
