Hello, sorry for replying this late, I'm looking into different things and my context switches are slow.
On Wed, Nov 24 2021, Mohamed Atef wrote: > Hello everyone, > I need to remind you that we are working on implementation of OMPD, so > you don't make it open for GSoC this year. I can assure you we will not accept an OMPD-implementation GSoC project, because I consider it just too big for effort of one individual. > > our progress so far, > We are working on a GDB extension using python so we can provide OMPD with > callbacks. > Jakub said that we need GDB support, but the GDB community didn't reply to > us although we mailed them more than one time, so is it okay to build the > plugin and extend GDB with python for testing purposes ? I *think* that since the "third party" should use OMPD library in a OpenMP-implementation-agnostic way, for this particular bit you should be able to look at how clang OMPD guys have "hacked" gdb to interface with the OMPD library ...and maybe re-use that without much extra effort? > > to enable OMPD the runtime must provide some routines like: > ompd_dll_locations_valid(void) > void ompd_bp_parallel_begin(void) > void ompd_bp_parallel_end(void) > void ompd_bp_task_begin(void) > void ompd_bp_task_end(void) > and define the variable const char **ompd_dll_locations. > so far so good , BUT OMPD can not access debug information at the runtime, > so it needs to access them What do you mean by "them?" these particular symbols, including the functions? Or internal run-time data structures in general? > We will write some macros for that. > the macros will generate the sizes and offsets for the following structs: > gomp_team > gomp_task_icv > > Should we generate all structs sizes? Jakub will eventually need to comment on this but please gie an example of what macroization you have in mind. If it is too ugly, we can discuss alternatives. Thanks, Martin
