Re: GNU OMPD implementation

[Mohamed Atef <mohamedatef1698@gmail.com>]

Hello,
     for the gdb part it's already understood. gdb documentation explains
how to extend gdb functionality using python, and we looked at clang code
and now it's very clear how to provide OMPD functions with parameters.

From OpenMP API specification 5.1 section 5.6
"The OpenMP implementation must define several entry point symbols through
which execution
must pass when particular events occur and data collection for OMPD is
enabled. A tool can enable
notification of an event by setting a breakpoint at the address of the
entry point symbol."

We need to add OMPD support to libgomp, and the debugger should be notified
that it has entered a new parallel region so we make dummy functions (or
labels) at every  start and end of (parallel, task, thread) regions (note :
they should not be optimized).

for the structures that we need to access in the runtime
for example here:

https://github.com/gcc-mirror/gcc/blob/master/libgomp/icv.c#L38

if OMPD needs to get the max threads of the target program it literally
repeat the call so we use callbacks to get the address of struct
gomp_task_icv then we read its value the we get the value of nthreads_var
variable
for example : callbacks->lookup(icv)->access(nthreads_var)

for now:
We finished the initialization phase and we're now working on how to test
the initialization of both the library and the target process.
We finished 5.5.1, 5.5.2, but for 5.5.4 i need to know the OpenMP version.
Where is the variable of the OpenMP version defined?

-----------

Current issues,

to get the variable names from the target needs to move from the debugger
space to the target process space to lookup the values so we can use
something like (std::map) to save the values of the symbols that we got
before but we don't use C++.
Can we use C++ ? . If not, Can we implement it ourselves?
Now we're thinking of leaving it as it's (access the target every time you
need to read or lookup.) and after finishing the project we can think of
something like caching the variables or any other way.

OMPD will support CPUs for now. Is that okay?

----------------

for the macroziation part:
the lookup and read_memory callbacks should be provided with the sizes of
the variable they need to look for or read?
OMPD doesn't know the size of runtime data structures and can not access
the dwarf at the runtime.
so we need to do that manually:
#define OMPD_FOREACH_SIZEOF(OMPD_SIZEOF)\
OMPD_SIZEOF(gomp_task_icv)\
OMPD_SIZEOF(gomp_task)\
OMPD_SIZEOF(gomp_team)

#define OMPD_DECLARE_SIZEOF(t) __UINT64_TYPE__ ompd_sizeof__##t;
OMPD_FOREACH_SIZEOF(OMPD_DECLARE_SIZEOF)
#undef OMPD_DECLARE_SIZEOF

we will generate these symbols as needed, so it's okay.

Thanks,

Mohamed



On Mon, Nov 29, 2021 at 3:55 PM Martin Jambor <mjambor@suse.cz> wrote:

> 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
>