GNU OMPD implementation

GNU OMPD implementation

[Mohamed Atef]

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.

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 ?

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

Are we on the right path?

I wish to hear from you soon.

Thanks,
    Mohamed

Re: GNU OMPD implementation

[Martin Jambor]

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

Re: GNU OMPD implementation

[Mohamed Atef]

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
>

Re: GNU OMPD implementation

[Mohamed Atef]

Hi,
    I forgot to give full details about macros.
after the declaration we got type called ompd_sizeof_(gomp_task) for example
then we can use sizeof operator to get its size:

#define OMPD_INIT_SIZEOF(t) ompd_sizeof_##t = sizeof(t);
    OMPD_FOREACH_SIZEOF(OMPD_INIT_SIZEOF)
#undef OMPD_INIT_SIZEOF

Thanks

Mohamed

On Tue, Nov 30, 2021 at 2:23 AM Mohamed Atef <mohamedatef1698@gmail.com>
wrote:

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

Re: GNU OMPD implementation

[Martin Jambor]

Hi,

On Tue, Nov 30 2021, Mohamed Atef wrote:
> 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.

great to hear that.

>
> 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 a proof of concept phase you can make them functions with attributes
used and noipa and we can figure out how to come up with a less terrible
solution later.

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

When you are ready to share some git repo or something, please do so.

> Where is the variable of the OpenMP version defined?

I do not know if there even is one.  The OpenMP implementation often has
only partial implementation of features in the newer versions of the
standard so coming up with one definitive version may be tricky.

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

Please don't use C++ for the runtime.  libgomp has a header file for
hash tables, but as you say...

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

...this can be dealt with later.  Unless it is not viable even for
simple testcases, starting with linear searches and improving later is
probably a better approach.

>
> OMPD will support CPUs for now. Is that okay?

Yes, absolutely.

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

Well, there is the ompd_callback_sizeof_fn_t thing... but I admit I am
not sure how exactly they envision it should be used, especially given
things like padding in between structure fields.

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

Again, Jakub will eventually have to accept the approach but I do not
see anything particularly wrong with it.  I just wonder whether you'll
need offsets of individual interesting fields as well.

Anyway, thanks for the encouraging news and good luck,

Martin

Re: GNU OMPD implementation

[Tobias Burnus]

Hi,

On 01.12.21 19:35, Martin Jambor wrote:
> On Tue, Nov 30 2021, Mohamed Atef wrote:
>> Where is the variable of the OpenMP version defined?

The GCC code itself does not make a difference, contrary to
C/C++/Fortran which have -std=....

OpenMP 4.5 (also known as 201511) is fully supported (minus bugs). Thus,
that's the version number (201511) reported to the user. For Fortran,
the 'openmp_version' parameter in the module 'omp_lib' and in omp_lib.h
come from libgomp/omp_lib.f90.in and libgomp/omp_lib.h.in. For C/C++ (or
Fortran with -cpp for the preprocessor), the value is in _OPENMP and is
defined in gcc/c-family/c-cppbuiltin.c.

However, while GCC only claims 4.5/201511 support, OpenMP 5.0 and 5.1
are partially implemented, cf.
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html

Thus, when a later version of the spec changed behavior, GCC might not
have 4.5 semantic but 5.0, 5.1 or even 5.2 (or later) semantic. This
happens either when implementing a 5.x feature or when a bug in the spec
was found which has then be fixed.

For completeness, for exported symbols in libgomp, some versioning
exists, cf. libgomp/libgomp.map.

Thanks for working on OMPD!

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

GNU OMPD implementation

[Mohamed Atef]

hello everyone,
we read chapter 5 and the paper proposed RWTH Aachen University and the
others
They worked on the same project.
some of us will work on OMPD, somebody will work on GDB plugin python
script and somebody will work on GDB support as jakub said ,
but i have some clarifications that might seem silly what do you mean by
GDB support and the header file specified in chapter 5 will be written
easily but we have a problem with the implementation itself where to
start?, do we miss something?, what are the basic knowledge we know C/C++
python and we have good understanding in Algorithms and Datastructures some
of the team members will compete in the regional ICPC contest this year
we understood the for gimple files
I am sorry if my questions might seem very basic or not?
What is the next step?
We are 6 students. How can the work be divided ?


Mohamed