Re: GSoC: Implementation of OMPD

[y2s1982 . via Gcc]

Hello Martin,

I have replied in-line.

On Tue, Mar 24, 2020 at 7:36 PM Martin Jambor  wrote:

> Hi Tony,
>
> sorry for a late reply, things are a bit crazy recently.
>

That's okay. Thanks for reaching back to me. I am still very interested.


> On Sat, Mar 07 2020, y2s1982 . wrote:
> > Hello everyone,
> >
> > My name is Tony Sim. In anticipation to planning for my last summer
> within
> > my degree program, I am considering to take part in the Google Summer of
> > Codes.  In particular, I would like to work on implementing OMPD for GCC
> > and related programs.
> >
> > I have studied CPU and GPU parallel programming in the span of two
> > semesters, which included OpenMP as a significant part of the
> curriculum. I
> > am quite fascinated by its possibilities and would love a chance to learn
> > more while tackling a real-world challenge.
> >
> > I would appreciate any additional information on the project.  It looks
> > very interesting. Really, it sounds like something I wish I had when I
> was
> > taking the course.
> >
>
> 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.


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


> The long-term goal is to implement that chapter 5 in libgomp, so that
> internal structures of libgomp and the run program can be exposed with
> this interface.  Of course, that would be too big a project for one
> summer, so the immediate goal would be to come up with an implementation
> of a subset that would behave well in a given set of contexts... and
> either make it consumable by GDB or at the very least demonstrate that
> it can be done.  Still a lot of work.
>

As you mentioned, the project seems ambitious, and one of the challenges
seemed to be setting a scope. Thank you for providing me with that
guideline.
So, if I may reiterate and make some more assumptions, the scope seems to
be: coming up with a proof-of-concept that may be replicated elsewhere to
complete the integration of OMPD.
This is exactly what I am interested in doing and gain valuable learning
experience while doing so.

>
> If you have any further questions, please feel free to ask.
>

I do have a question.
Debugging a program with OMP was challenging; if anything, the
race-condition alone made reproducing many bugs a probability issue.  I was
taught to give extra care on developing, optimizing, and debugging a
single-thread counterpart first before converting to an OMP application.
Would the OMPD make it possible for programmer to develop an OMP
application from ground-up, or would they still need to design the
single-threaded version first?


> Good luck with your GSoC!
>
> Martin
>

Re: Welcome GCC GSoC 2020 participants

[y2s1982 . via Gcc]

Hello Martin,

Thank you for a thorough reply. I have some updates and more questions for
you. I have put them inline.
In gist,
- FSF replied with signed assignment form; still working on getting Compile
Farm access
- Generated bunch of GIMPLE dump and looked at few of them
- I proposed some form of workflow and would like some suggestions
- I looked at documentations and clang repository for OMPD and have some
questions.

On Mon, May 18, 2020 at 11:32 AM Martin Jambor  wrote:

> Hello Tony,
>
> sorry for not getting back to you last week.  Time seems to fly even
> faster now that I'm forced to work from home :-/  Furthermore, both me
> and Jakub have been preparing for a big OpenMP meeting that takes place
> this week.
>

Wow, is that meeting something I may attend? It sounds like an amazing
learning opportunity.


>
> On Tue, May 12 2020, y2s1982 . wrote:
> > Hello Martin and Jakub,
> >
> > This is Tony Sim. I am excited to report that I have been getting some
> > documentation out of the way in the past few weeks.
> > - I have submitted a signed application to ass...@gnu.org. I had a corr-
> > -espondence with Craig and have submitted a signed document last
> Thursday.
> > I have not heard back since.
>
> Great.  The processing was likely to take some time but if they still do
> not get back to you this week, please ping them.
>

I got a reply from Craig yesterday with the form that has both signatures.
It seems that part is now complete.


>
> > - I have requested an account to the Compile Farm. I got a welcome email
> to
> > a cf mailing list, but I do not know how to log in to the web portal or
> get
> > the SSH key to the servers. I never had a chance to assign a password nor
> > do i get a reply when I click on the "Lost Password" button. Should I
> > request for it again?
>
> I requested an account at the compile farm so long time ago that I do
> not remember the process.  Some sort of password can be re-set at
> https://cfarm.tetaneutral.net/ but as far as I can remember it is only
> needed to upload your public SSH key.  Please reach out to admins as
> described at https://cfarm.tetaneutral.net/tickets/ if you still cannot
> access your account.
>
> By the way, you don't "get" an SSH key, you upload the public part of
> the one you have generated yourself.
>

Oh, that makes sense: private keys shouldn't be shared. I do have a public
key, so I will share it when given the opportunity. I will reach out to the
Compile Farm later this week to inquire more on the progress of the
application.


>
> > - I have said greetings on IRC. I had two replies :) I haven't used IRC
> for
> > some years, and am trying to get my client to work exactly as how I would
> > like it
>
> Good.  This morning I have seen your last messages in the IRC log... and
> again, sorry for not getting back to you earlier.  Anyway, I hope that
> you got some of the questions you asked answered, and please ask again,
> even via email, if some still remain.  The time zone difference might
> work against us (both I and Jakub are on Central European time) but IRC
> tends to be a valuable tool nevertheless.
>
> About "how do I contribute" question you asked on IRC: I think it's
> going to take a little while before we get to that but once you have the
> FSF copyright assignment and something to contribute, we'll get you an
> account allowing you to commit after approval directly to the upstream
> repo - after approval means once your patch has been officially approved
> by the respective maintainer on the gcc-patches mailing list.
>
> At this point, I'd suggest that you simply clone our git repo and start
> experimenting.  Patch-via-email is likely to be the most used way of
> discussing code.  At some point we'll probably need a branch, that can
> initially sit either on gcc git server or anywhere else, really.  There
> is a mirror both at gitlab (https://gitlab.com/x86-gcc/gcc) or github
> (https://github.com/gcc-mirror/gcc) and many other git hosting services,
> for example.  Whatever fits your philosophical or practical preferences.
>

If it is all the same, and since I am familiar with working on github, may
I work on github?  I took the liberty of creating the fork of gcc-mirror to
my account. I would like to create a major develop branch within the fork,
and create minor develop branches from that branch. I would also like to
plan out my tasks using their Issue tracking system. The minor develop
branch code would be reviewed via PR by any interested parties,
particularly Jakub, after which it would be squash-merged to the major
develop branch of the fork.  We can discuss further on the interval for the
patch-via-email process to merge the code to upstream, which I assume would
happen when the code reaches certain maturity, or at least at the end of
this project. I also would like to know how often I should pull from
upstream to keep the fork up to date.  I would also welcome any suggestions
on improvements or changes to the overal

GSoC: OMPD conversation

[y2s1982 . via Gcc]

Hello team,

I just wanted to give an update to my current progress. I spent most of the
time looking over OMPD documentation again and studying LLVM's approach to
it.


> >
> > If it is all the same, and since I am familiar with working on github,
> may
> > I work on github?  I took the liberty of creating the fork of gcc-mirror
> to
> > my account. I would like to create a major develop branch within the
> fork,
> > and create minor develop branches from that branch. I would also like to
> > plan out my tasks using their Issue tracking system. The minor develop
> > branch code would be reviewed via PR by any interested parties,
> > particularly Jakub, after which it would be squash-merged to the major
> > develop branch of the fork.  We can discuss further on the interval for
> the
> > patch-via-email process to merge the code to upstream, which I assume
> would
> > happen when the code reaches certain maturity, or at least at the end of
> > this project.
>
> If that is how you like to work, I guess we can try it out.  Just please
> keep in mind that:
>
> 1) We are used to reviewing patches in our email clients and prefer it
>to reviews in web-based tools.  I have quite a lot of customizations
>in place that I am used to and so prefer it to
>one-method-fits-everyone web tools.
>
I understand. This kind of information is exactly what I wanted to know so
I can adjust my work process to fit the community needs. My I follow the
above process of making PR but also create a patch using 'git diff' command
and share that with the mailing list?

>
> 2) Do not spend too much time thinking about how to organize the
>project.  The time is better spent actually thinking about the
>project itself, particularly because I expect this one to entail a
>lot of experimenting with an occasional dead end.
>
I understand. I just thought this discussion belonged to me getting to know
how to work with the community and therefore fit the community bonding
period theme. I am very excited to get to actually work, too.

>
> >> Having said that, if you'd like to do a hangouts video call to say hello
> >> to each other and perhaps to discuss some issues with setting up your
> >> work, I personally am definitely happy to do that too.  As a regular
> >> communication tool, I did not find videoconferencing to be very useful
> >> in the past (but I guess I can be persuaded to try again).
> >
> > Hmm. In my last coop that ended during pandemic, we used the video
> > conferencing tool to do daily stand-ups so the team can keep tabs on how
> > different parts of the project is going and give suggestions as needed. A
> > little off-topic, but how often would you like to discuss my progress of
> > the project?
>
> So... ideally the stream of emails discussing the overall approach,
> followed by a stream of patches and reviews would make it completely
> unnecessary to ask you for some kind of regular status reports.
> Nevertheless, if some task takes you more than a 4-5 work-days in which
> you don't get back to us, please send us a quick summary of what you
> have been working on.  This arrangement of course means that you need to
> reach out to us if you believe you are stuck, so please do.
>
> But let me reiterate that I am willing to try a videoconference or two
> if you think it would be useful at any point.
>
Would it be nice to have a face-to-face conversation perhaps in the first
week of June? Perhaps open to any interested community member to discuss
the beginnings of the OMPD?


>
> >>
> >> Dumps will show you what the compiler produces but most of the work in
> >> this project will probably be done in the run-time library libgomp.  So
> >> look at its source, the generated dump files should show you what are
> >> the entry points and when they are called.  Please make sure you
> >> understand how the library works for simple OpenMP (example) programs.
> >> Ask more questions.
> >>
> > I will try compiling the test cases you mentioned and try to understand
> the
> > gimple more in depth. I will also try to see which part of the libgomp is
> > making the translation. Is it correct for me to assume that libgomp is
> all
> > about reading C code and manipulate GIMPLE?
> >
>
> No, GCC, the compiler, reads C and then goes through various stages of
> intermediate representations of the C code, one of which is gimple,
> optimizes it and produces an assembly.
>
> If that C file contains OpenMP directives (and you compile with
> -fopenmp) many of those are converted in one way or another into calls
> into the "GNU offloading and multi-processing (run-time) library:"
> libgomp.  It used to be just GNU OpenMP library but now it is also the
> run-time library for OpenACC.
>
> For example, #pragma omp parallel is compiled in a way that the body of
> the construct is outlined into a special artificial function and the
> construct itself is compiled into a call to a function GOMP_parallel,
> with a reference to the function w

Re: GSoC: OMPD conversation

[y2s1982 . via Gcc]

Hello,

On Thu, Jun 4, 2020 at 6:54 PM Martin Jambor  wrote:

> Hi,
>
> On Sun, May 31 2020, y2s1982 . wrote:
> > Hello team,
> >
> > I just wanted to give an update to my current progress. I spent most of
> the
> > time looking over OMPD documentation again and studying LLVM's approach
> to
> > it.
> >
>
> thanks a lot, sorry about replying this late again, unfortunately I
> missed your email on Monday and only noticed it yesterday.
>

> [...]
>
> >>
> >> 1) We are used to reviewing patches in our email clients and prefer it
> >>to reviews in web-based tools.  I have quite a lot of customizations
> >>in place that I am used to and so prefer it to
> >>one-method-fits-everyone web tools.
> >>
> > I understand. This kind of information is exactly what I wanted to know
> so
> > I can adjust my work process to fit the community needs. My I follow the
> > above process of making PR but also create a patch using 'git diff'
> command
> > and share that with the mailing list?
>
> yeah, sure, although I think people usually use git format-patch.
>

Oh okay. This is the exact kind of information I was looking for :D.  I was
looking at the command, too, but I wasn't sure how exactly to use it. I
will look more into it and learn.

>
> > In an effort to understand how I might go about starting the OMPD
> project,
> > I spent some time studying LLVM's attempt. Following are my findings and
> > some questions.
> >
> > The LLVM's repository for OMPD development is at this github repo
> > ,
> > under the branch ompd-test.
> > The OMPD documentation
> > 
> states
> > that the omp-tools.h be available.
>
> I believe it is
> https://github.com/OpenMP/sources/blob/master/include/omp-tools.h
>
> It should be referenced somewhere from the openmp.org but possibly
> actually isn't.
>

Hmm, does this mean the file should be or is already imported via autoconf?
I also assume I should have at least a dummy definition for all declared
prototypes when the header file is included.


>
> > The closest thing to this I found
> > was in this
> > .var file
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/runtime/src/include/50/omp-tools.h.var
> >,
> > though I am not familiar enough to understand how this translate to
> > omp-tools.h file later.  After this, things got a little more
> interesting.
> > First, they seem to be using GNU gdb as the debugger. From there, their
> older
> > attempt
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-wrapper
> >,
> > stored
> > in a folder called "gdb-wrapper", seems to work around with creating a
> > C/C++ wrapper. This seems to be in the process of being replaced with
> > gdb-plugin idea, as represented in this git issue
> >  and
> their
> > current CMakeList.txt
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/libompd/CMakeLists.txt
> >.
> > The gdb-plugin
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-plugin
> >
> > seems
> > to rely on python to implement OMPD.
>
> So by now you may know quite a bit more about LLVM's OMPD effort than I
> do but it rather seems like they use the python gdb scripts to call into
> a python module written in C - which in term uses OMPD interface to get
> information about the debugged program - in order to provide the user
> with useful OpenMP context.  I only looked at them quickly but they do
> not look anything like an implementation.
>
>
Yes, they do call gdb via Python. I wasn't sure if that's what I was
supposed to do or not.
Good thing you clarified that for me just now :D


>
> > For example, other than the fact that
> > most of the code in the folder is written in python, the ompdModule.c's
> > _read()
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/gdb-plugin/ompdModule.c#L504-L534
> >,
> > which corresponds to ompd_callback_memory_read_fn_t typedef
> > <
> https://www.openmp.org/spec-html/5.0/openmpsu209.html#x264-17550005.4.3.2>
> > defined
> > in the OMPD documentation, creates and manipulates PyObject throughout
> the
> > function implementation.
>
> Right.  But looking at the python scripts I really tend to think they
> are simply OMPD users.
>

> >
> > I am left with a couple of questions:
> > First of all, they seem to be working with gdb to provide OMPD solution
> in
> > forms of wrapper/plugin. Can we use this code, too? What kind of issues
> do
> > we have with licensing?
>
> We do take the sanitizer run-time library code from LLVM upstream, so I
> think it is possible, in principle.  but...
>
> >
> > Secondly, the LLVM team started from C/C++ wrapper and moved on to Python
> > implementation.
>
> ...again, maybe I'm misunderstanding you, but

[OMPD] regarding const char **ompd_dll_locations

[y2s1982 . via Gcc]

Hello everyone,

I would like to share some of my thoughts and seek some opinions on coding
for const char **ompd_dll_locations.

After reviewing the documentation
, looking over LLVM
approach

as a reference, looking around in GCC code base, and searching around for
similar cases and their solutions, I have just a few more questions before
finally putting down some unit tests and code.

- This post
seems
to use compiler macro to rely on the compiler to suggest architecture,
including 32bit and 64bit. I found some macro in gcc/config/i386/i386.h
that seems relevant. Is this an acceptable approach? If yes, which header
should I use? If not, should I then compare byte size of int and decide
from there?

- I did some digging around to find conventional library location.  One of
the issue, however, is that my Linux x86 64bit machine is currently down
for repair. I checked in my FreeBSD x86 64bit machine, which suggested
/usr/lib for 64bit library and /usr/lib32 for 32bit library, and my
raspberry pi Linux 64bit ARM, which suggested /usr/lib/aarch64-linux-gnu
for 64bit library. At the moment, I assumed I would keep the scope small
and stay with x86 machine's 32bit and 64bit machines, but I wasn't sure
what would be the best path to put in that would accommodate all machines.
I haven't even looked into Windows, although I assume it's likely
C:\Program Files\system and C:\Program Files\system32. Should I simply put
all possible path into the array per arch?
(LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this was
just a placeholder.)

- There doesn't seem to be any dedicated function to assign values to the
variable. I would like to create a header file to declare some additional
functions, such as one that would assign the value. Is this acceptable and,
if so, where would be the best place to put such header file?

I would appreciate any suggestions.

Cheers and stay safe,

Tony Sim

Re: [OMPD] regarding const char **ompd_dll_locations

[y2s1982 . via Gcc]

Hello Jakub,

Thank you for the quick response. I assume, then, there's no need for
making a function to set this global variable at this point. Should I
create a simple unit test that asserts the value to be "libgompd.so.1" for
now, or should I skip the unit test on this for now?

Cheers,

Tony Sim

On Thu, Jun 18, 2020 at 5:36 PM Jakub Jelinek  wrote:

> On Thu, Jun 18, 2020 at 05:24:25PM -0400, y2s1982 . wrote:
> > (LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this
> was
> > just a placeholder.)
>
> Let's put there { "libgompd" SONAME_SUFFIX (1), NULL } for now.
> You'll need to change the SONAME_SUFFIX macros though - remove the ()s
> around the strings, so that it can be further concatenated.
>
> libgomp/config/darwin/plugin-suffix.h:#define SONAME_SUFFIX(n) ("." #n
> ".dylib")
> libgomp/config/posix/plugin-suffix.h:#define SONAME_SUFFIX(n) (".so." #n)
> libgomp/config/hpux/plugin-suffix.h:#define SONAME_SUFFIX(n) (".sl." #n)
> libgomp/target.c:  const char *suffix = SONAME_SUFFIX (1);
>
> Jakub
>
>

[OMPD] API version formatting

[y2s1982 . via Gcc]

Hello,

I have a question on API version formatting.
I have been looking at the get_api_version() and get_api_version_string()
documentation:
https://www.openmp.org/spec-html/5.0/openmpsu213.html#x269-17920005.5.1.2
I also saw how LLVM implements it using macro to store the information:
https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.h#L22-L28
These values are then used here:
https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.cpp#L1344-L1358

I could not, however, find any supporting documentation to refer to, and I
wanted to know how we should go about formatting this or if LLVM's
formatting convention is acceptable.

Cheers,

Tony Sim

Re: [OMPD] API version formatting

[y2s1982 . via Gcc]

On Mon, Jun 22, 2020 at 1:54 PM Jeffrey Walton via Gcc 
wrote:

> On Mon, Jun 22, 2020 at 1:47 PM Jakub Jelinek via Gcc 
> wrote:
> >
> > On Sat, Jun 20, 2020 at 01:26:59PM -0400, y2s1982 . via Gcc wrote:
> > > I have a question on API version formatting.
> > > I have been looking at the get_api_version() and
> get_api_version_string()
> > > documentation:
> > >
> https://www.openmp.org/spec-html/5.0/openmpsu213.html#x269-17920005.5.1.2
> > > I also saw how LLVM implements it using macro to store the information:
> > >
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.h#L22-L28
> > > These values are then used here:
> > >
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.cpp#L1344-L1358
> >
> > We don't support any TRs and I think we aren't going to, so just encoding
> > there the 5.0 numbers should be good enough.
> > If the 4 separate bytes of the version isn't something written somewhere
> in
> > the standard, I'd use something along the lines of
> > #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
> > macro, so make it
> > #define OMPD_VERSION (5 * 1 + 0 * 100 + 0)
> > so there is some room for minor revisions below that.
>
> I may be mistaken, but I believe OpenMP version information is
> provided in the OPENMP macro. It is a date,and it is used to detect
> the conformance level of OpenMP.
>
> For example, to avoid compile problems with code that can be compiled
> with MSVC (Microsoft provides an ancient version of OpenMP):
>
> inline void BlockCopy(byte* dest, byte* src, size_t len)
> {
> // OpenMP 4.0 released July 2013.
> #if _OPENMP >= 201307
> #pragma omp simd
> for (size_t i = 0; i < len; ++i)
> dest[i] = src[i];
> #else
> for (size_t i = 0; i < len; ++i)
> dest[i] = src[i];
> #endif
> }
>
> Jeff
>

Another thing I was wondering about (thanks Jeff for reminding me): is OMPD
versioning dependent on OpenMP versioning, and how should I address that?

[OMPD] Library Functions

[y2s1982 . via Gcc]

Hello everyone,

For this week, I wanted to complete the OMPD library-wide functions, namely
the ompd_initialize and ompd_finalize.  I took notes from:
- https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf
,
-
https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/libompd/src/omp-debug.cpp
,
and
-
https://github.com/OpenMPToolsInterface/OMPD-Technical-Report/blob/master/ompd-tr.pdf
.

It currently has some small changes (see attached) and wanted to get some
feedback on it and what more I should do for these functions.

In particular, I declared a non-static, non-const variable called
gompd_callbacks that would store an independent copy of ompd_callbacks_t.
This is different from how OpenMPToolsInterface's LLVM team has done it:
they have a static const variable that simply stores the pointer value that
was passed in.  The reason for my approach was because the
OpenMPToolsInterface's document repo stated that the argument passed in
cannot be assumed to be unchanged after the function call is completed.

My hesitation is because this is not specified in the OpenMP 5.0 API
specification document.

I would appreciate any feedback.

Cheers,

Tony Sim
From cef95b0d0c63eb364faa3d510f439bbf36a82999 Mon Sep 17 00:00:00 2001
From: y2s1982 
Date: Tue, 30 Jun 2020 18:46:34 -0400
Subject: [PATCH] libompd: added more OMPD library-wide functions


2020-06-30  Tony Sim  

libgomp/ChangeLog:

	* libgompd.h : Add gompd_callbacks variable.
	* ompd-lib.c (ompd_finalize): Add new function.

---
 libgomp/libgompd.h |  4 
 libgomp/ompd-lib.c | 15 ++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/libgomp/libgompd.h b/libgomp/libgompd.h
index 9782828bff5..2aedeecaa38 100644
--- a/libgomp/libgompd.h
+++ b/libgomp/libgompd.h
@@ -29,9 +29,13 @@
 #ifndef LIBGOMPD_H
 #define LIBGOMPD_H 1
 
+#include "omp-tools.h"
+
 #define ompd_stringify(x) ompd_str2(x)
 #define ompd_str2(x) #x
 
 #define OMPD_VERSION 201811
 
+ompd_callbacks_t* gompd_callbacks;
+
 #endif /* LIBGOMPD_H */
diff --git a/libgomp/ompd-lib.c b/libgomp/ompd-lib.c
index f0ae9e85a7e..4513dadc070 100644
--- a/libgomp/ompd-lib.c
+++ b/libgomp/ompd-lib.c
@@ -28,6 +28,7 @@
 
 #include "omp-tools.h"
 #include "libgompd.h"
+#include 
 
 ompd_rc_t
 ompd_get_api_version (ompd_word_t *version)
@@ -49,13 +50,25 @@ ompd_initialize (ompd_word_t api_version, const ompd_callbacks_t *callbacks)
 {
   static int ompd_initialized = 0;
 
+  if (!callbacks)
+return ompd_rc_bad_input;
+
   if (ompd_initialized)
 return ompd_rc_error;
 
+  gompd_callbacks = malloc(sizeof(ompd_callbacks_t));
+  *gompd_callbacks  = *callbacks;
+
   (void) api_version;
-  (void) callbacks;
 
   ompd_initialized = 1;
 
   return ompd_rc_ok;
 }
+
+ompd_rc_t
+ompd_finalize(void)
+{
+  free (gompd_callbacks);
+  return ompd_rc_ok;
+}
-- 
2.27.0

[OMPD] Questions on per-process functions and related data types.

[y2s1982 . via Gcc]

Hello,

In addition to the per-library process, I am trying to implement OMPD's
per-process functions defined in 5.5.2.
I have some questions on defining or at least using some of the data types.

In the attached patch, I took a liberty of tentatively defining the
_ompd_aspace_handle, which is the ompd_address_space_handle_t. This was not
explicitly defined by the standard. I took notes from the LLVM project to
come up with one, although I chose to retain some of the member variable
data types. Are they sufficient? I am not sure about the id variable. It
seems to be mainly added in the ompd_device_initialize function, but the
argument passed in is void *id. It is accompanied by sizeof_id that denotes
the size. I chose to keep the void pointer and stored the sizeof_id in the
struct, but is there a better way?

Another one that is used in the 5.5.2 section that isn't explicitly defined
is the _ompd_aspace_cont, which is the ompd_address_space_context_t. It
seems I need to read data from this, but I do not know how it should be
defined. Any suggestions?

As always, please feel free to let me know of any mistakes or other
suggestions regarding the patch.

Cheers,

Tony Sim
From 72ec5149a1296ef9f773529b486b9100ef0b8891 Mon Sep 17 00:00:00 2001
From: y2s1982 
Date: Wed, 1 Jul 2020 22:47:25 -0400
Subject: [PATCH] libgomp: Add OMPD library and process functions

This patch adds OMPD library initialize and finalize functions, and OMPD
process initialize and resource release functions. It also imports
ompd-types.h that defines additional macros and data types.

2020-07-01  Tony Sim  

libgomp/ChangeLog:

	* Makefile.am (libgompd_la_SOURCES): Add ompd-proc.c.
	* Makefile.in: Regenerate.
	* libgompd.h: Include omp-tools.h.
	(gompd_callbacks): Add new extern declaration.
	* ompd-lib.c (ompd_initialize): Simplified copy logic.
	(ompd_initialized): Moved to global scope.
	(ompd_finalize): Add new function that resets flag.
	* ompd-proc.c: New file.
	* ompd-types.h: New file.

---
 libgomp/Makefile.am  |  2 +-
 libgomp/Makefile.in  |  9 ++--
 libgomp/libgompd.h   |  4 ++
 libgomp/ompd-lib.c   | 16 +++-
 libgomp/ompd-proc.c  | 95 +++
 libgomp/ompd-types.h | 97 
 6 files changed, 216 insertions(+), 7 deletions(-)
 create mode 100644 libgomp/ompd-proc.c
 create mode 100644 libgomp/ompd-types.h

diff --git a/libgomp/Makefile.am b/libgomp/Makefile.am
index e15a838e55c..e5556ef61e5 100644
--- a/libgomp/Makefile.am
+++ b/libgomp/Makefile.am
@@ -90,7 +90,7 @@ libgomp_la_SOURCES = alloc.c atomic.c barrier.c critical.c env.c error.c \
 	oacc-mem.c oacc-async.c oacc-plugin.c oacc-cuda.c priority_queue.c \
 	affinity-fmt.c teams.c allocator.c oacc-profiling.c oacc-target.c
 
-libgompd_la_SOURCES = ompd-lib.c
+libgompd_la_SOURCES = ompd-lib.c ompd-proc.c
 
 include $(top_srcdir)/plugin/Makefrag.am
 
diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index af897d6c6ba..f0f91761a0d 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -235,7 +235,7 @@ am_libgomp_la_OBJECTS = alloc.lo atomic.lo barrier.lo critical.lo \
 	$(am__objects_1)
 libgomp_la_OBJECTS = $(am_libgomp_la_OBJECTS)
 libgompd_la_LIBADD =
-am_libgompd_la_OBJECTS = ompd-lib.lo
+am_libgompd_la_OBJECTS = ompd-lib.lo ompd-proc.lo
 libgompd_la_OBJECTS = $(am_libgompd_la_OBJECTS)
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -574,10 +574,10 @@ nodist_toolexeclib_HEADERS = libgomp.spec
 libgomp_version_info = -version-info $(libtool_VERSION)
 libgompd_version_info = -version-info $(libtool_VERSION)
 libgomp_la_LDFLAGS = $(libgomp_version_info) $(libgomp_version_script) \
-$(lt_host_flags)
+	$(lt_host_flags)
 
 libgompd_la_LDFLAGS = $(libgompd_version_info) $(libgompd_version_script) \
-$(lt_host_flags)
+	$(lt_host_flags)
 
 libgomp_la_DEPENDENCIES = $(libgomp_version_dep)
 libgompd_la_DEPENDENCIES = $(libgompd_version_dep)
@@ -592,7 +592,7 @@ libgomp_la_SOURCES = alloc.c atomic.c barrier.c critical.c env.c \
 	oacc-async.c oacc-plugin.c oacc-cuda.c priority_queue.c \
 	affinity-fmt.c teams.c allocator.c oacc-profiling.c \
 	oacc-target.c $(am__append_4)
-libgompd_la_SOURCES = ompd-lib.c
+libgompd_la_SOURCES = ompd-lib.c ompd-proc.c
 
 # Nvidia PTX OpenACC plugin.
 @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_version_info = -version-info $(libtool_VERSION)
@@ -817,6 +817,7 @@ distclean-compile:
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/oacc-profiling.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/oacc-target.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ompd-lib.Plo@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ompd-proc.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ordered.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parallel.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/priority_queue.Plo@am__quote@
diff --git a/libgomp/libgompd.

Re: [OMPD] Questions on per-process functions and related data types.

[y2s1982 . via Gcc]

Hello,

Thank you for the detailed reply. I have some questions.

On Thu, Jul 2, 2020 at 8:47 AM Jakub Jelinek  wrote:

> On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote:
> > per-process functions defined in 5.5.2.
> > I have some questions on defining or at least using some of the data
> types.
>
> The standard makes those intentionally not defined, it is up to the
> implementation to put in there whatever is needed/useful.  That is the
> whole
> idea behind handles, which are pointer to these, but it is not ok for the
> debugger to make assumptions on what exactly it points to
> (similarly how e.g. with the context handles which are again pointers to
> some data in the debugger and OMPD shouldn't assume anything, just pass it
> around).
>

I thought I understood this part, but I just need a little more nudge. I
get that standard left it
to the discretion to the implementation, and I assumed we would be the ones
to define
them. Is it okay to define the handle? Also, is the context only stored in
the OMPD and
is only used when passed back to the debugger so that debugger understands
the context
to the information OMPD gave back to it? Does that mean any of the
functions I use should
not try to get information from it?  Does this also mean I shouldn't free
up the context pointers
when releasing the handle as the information is handled by the debugger?


>
> > --- a/libgomp/libgompd.h
> > +++ b/libgomp/libgompd.h
> > @@ -29,9 +29,13 @@
> >  #ifndef LIBGOMPD_H
> >  #define LIBGOMPD_H 1
> >
> > +#include "omp-tools.h"
> > +
> >  #define ompd_stringify(x) ompd_str2(x)
> >  #define ompd_str2(x) #x
> >
> >  #define OMPD_VERSION 201811
> >
> > +extern ompd_callbacks_t gompd_callbacks;
> > +
>
> Confused, weren't these changes already in the previous patch?
> (and other hunks too).
>
I didn't get any reply and wasn't sure if the patch was approved.
I also needed the gompd_callbacks to define the functions.
I then thought they were small enough and similar enough changes to
combine into a single patch.  Should I keep them separated?


> >  #endif /* LIBGOMPD_H */
> > diff --git a/libgomp/ompd-lib.c b/libgomp/ompd-lib.c
> > index f0ae9e85a7e..d5350e1045c 100644
> > --- a/libgomp/ompd-lib.c
> > +++ b/libgomp/ompd-lib.c
> > @@ -29,6 +29,9 @@
> >  #include "omp-tools.h"
> >  #include "libgompd.h"
> >
> > +ompd_callbacks_t gompd_callbacks;
> > +static int ompd_initialized = 0;
> > +
> >  ompd_rc_t
> >  ompd_get_api_version (ompd_word_t *version)
> >  {
> > @@ -47,15 +50,24 @@ ompd_get_version_string (const char **string)
> >  ompd_rc_t
> >  ompd_initialize (ompd_word_t api_version, const ompd_callbacks_t
> *callbacks)
> >  {
> > -  static int ompd_initialized = 0;
> > +  if (!callbacks)
> > +return ompd_rc_bad_input;
> >
> >if (ompd_initialized)
> >  return ompd_rc_error;
> >
> > +  gompd_callbacks = *callbacks;
> > +
> >(void) api_version;
> > -  (void) callbacks;
> >
> >ompd_initialized = 1;
> >
> >return ompd_rc_ok;
> >  }
> > +
> > +ompd_rc_t
> > +ompd_finalize (void)
> > +{
> > +  ompd_initialized = 0;
> > +  return ompd_rc_ok;
> > +}
> > diff --git a/libgomp/ompd-proc.c b/libgomp/ompd-proc.c
> > new file mode 100644
> > index 000..6a9c827e327
> > --- /dev/null
> > +++ b/libgomp/ompd-proc.c
> > @@ -0,0 +1,95 @@
> > +/* Copyright (C) 2020 Free Software Foundation, Inc.
> > +   Contributed by Yoosuk Sim .
> > +
> > +   This file is part of the GNU Offloading and Multi Processing Library
> > +   (libgomp).
> > +
> > +   Libgomp is free software; you can redistribute it and/or modify it
> > +   under the terms of the GNU General Public License as published by
> > +   the Free Software Foundation; either version 3, or (at your option)
> > +   any later version.
> > +
> > +   Libgomp is distributed in the hope that it will be useful, but
> WITHOUT ANY
> > +   WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
> > +   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> > +   more details.
> > +
> > +   Under Section 7 of GPL version 3, you are granted additional
> > +   permissions described in the GCC Runtime Library Exception, version
> > +   3.1, as published by the Free Software Foundation.
> > +
> > +   You should have received a copy of the GNU General Public License and
> > +   a copy of the GCC 

Re: [OMPD] Questions on per-process functions and related data types.

[y2s1982 . via Gcc]

On Thu, Jul 2, 2020 at 11:12 AM Jakub Jelinek  wrote:

> On Thu, Jul 02, 2020 at 10:57:11AM -0400, y2s1982 . wrote:
> > > On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote:
> > > > per-process functions defined in 5.5.2.
> > > > I have some questions on defining or at least using some of the data
> > > types.
> > >
> > > The standard makes those intentionally not defined, it is up to the
> > > implementation to put in there whatever is needed/useful.  That is the
> > > whole
> > > idea behind handles, which are pointer to these, but it is not ok for
> the
> > > debugger to make assumptions on what exactly it points to
> > > (similarly how e.g. with the context handles which are again pointers
> to
> > > some data in the debugger and OMPD shouldn't assume anything, just
> pass it
> > > around).
> > >
> >
> > I thought I understood this part, but I just need a little more nudge. I
> > get that standard left it
> > to the discretion to the implementation, and I assumed we would be the
> ones
> > to define
> > them. Is it okay to define the handle? Also, is the context only stored
> in
>
> Yes.  But only in libgompd.h, not in omp-tools.h.  I.e. anything outside of
> libgompd.so shouldn't have a way to find out what it is and how to access
> it.
> Similarly, the ompd_address_space_context_t is something that is owned by
> the debugger, OMPD should have no business to look at it, only pass the
> pointer to the callbacks.
> The objects allocated by OMPD that are OMPD-internal of course may not be
> freed by anything but OMPD itself, and similarly something that is private
> to the debugger and OMPD doesn't know the size/what it contains shouldn't
> be
> freed by OMPD.
>
This is giving me more clarity on what I have to do. At the moment, I am
storing the
information in the handle.

I do have one problem: in 5.5.2.1 (
https://www.openmp.org/spec-html/5.0/openmpsu214.html#x270-18090005.5.2)
it states that the call may verify the version compatibility using the
context.
How should I handle this?

The version compatibility is something I am also struggling with. I don't
know if
the higher version is backward compat with all earlier versions or like
automake,
where each version may or maynot be compatible with the earlier versions.


> > I do have a question: as handle is considered the output of the function,
> > should
> > I still assume it is not NULL when passed in?
>
> Depends on what the standard says.  If it is unspecified behavior what
> happens if it is NULL, then you can assume it is non-NULL and don't even
> need to check for NULL, if it says what should happen when NULL is passed,
> you should follow that.
>
I realized I was being dumb: if no address to the pointer is passed in,
there's no place to write the output.
The document also states that the tool owns the address space, so I assume
the tool
created the handle before passing in the address to its own pointer.  I
will check for NULL.



Cheers,

Tony Sim

Re: [OMPD] Questions on per-process functions and related data types.

[y2s1982 . via Gcc]

Hello,

On Fri, Jul 3, 2020 at 10:06 AM Jakub Jelinek  wrote:

> On Thu, Jul 02, 2020 at 06:58:49PM -0400, y2s1982 . via Gcc wrote:
> > This is giving me more clarity on what I have to do. At the moment, I am
> > storing the
> > information in the handle.
> >
> > I do have one problem: in 5.5.2.1 (
> > https://www.openmp.org/spec-html/5.0/openmpsu214.html#x270-18090005.5.2)
> > it states that the call may verify the version compatibility using the
> > context.
> > How should I handle this?
>
> It is up to the implementation to decide what can it handle and what it
> can't, the OMPD will be evolving, new callbacks will be added, old ones
> deprecated etc.
> As initially there will be just a single version supported (the 5.0 one),
> until 5.1 is implemented we should just reject any incompatible versions,
> and only when we implement 5.1 decide if we can accept 5.0 requests.
>

Thank you for the clarity on this. The task seems simple for now with
respect
to version compatibility.

Still, following the documentation 5.5.2.1, how should I extract version
information from ompd_address_space_context_t that is owned by the
debugger instead of the OMPD to check for compatibility , especially
when it is not currently defined?

Should I leave that portion for later?

Cheers,

Tony Sim


>
> Jakub
>
>

Re: [OMPD] Questions on per-process functions and related data types.

[y2s1982 . via Gcc]

Hello Jakub,

On Fri, Jul 3, 2020 at 10:40 AM Jakub Jelinek  wrote:

> On Fri, Jul 03, 2020 at 10:26:27AM -0400, y2s1982 . wrote:
> > Still, following the documentation 5.5.2.1, how should I extract version
> > information from ompd_address_space_context_t that is owned by the
> > debugger instead of the OMPD to check for compatibility , especially
> > when it is not currently defined?
>
> For ompd_process_initialize, you can use the callbacks to find out anything
> you want.
> In particular, e.g. ompd_callback_symbol_addr_fn_t callback can be used to
> look up some magic symbol that you'd add to libgomp.so.1
> (GOMP_library_details or whatever else), which would be some (ideally
> read-only) data variable that will describe everything OMPD needs to know
> about the library; if that symbol isn't found, you'd say it is
> incompatible,
> if it is found, you'd read it and parse it.
>

Thank you for clarifying how ompd_callback_symbol_addr_fn_t callback can
used. Are there any existing symbols I can lookup using this function and
the
current libgomp.so.1, such as information on cuda device id?


> It would be nice if the variable contains data in some extensible format,
> which would allow for compatible (one version of libgompd.so.1 handling
> older or newer libgomp.so.1) or incompatible (something OMPD will not be
> able to deal with) changes and encode everything you'll need to know
> (offsets into internal structures where needed, their sizes, etc.) in some
> compact form.  You can use the ompd_callback_memory_read_fn_t callback
> to read data from that variable.

What kind of information should I put in? At the moment, I am thinking of
creating
a packet with following memory structure: a header portion of one byte that
represents
the total byte size of the encoded packet, followed by a series of bits,
each representing
compatibility of a particular OMPD version. I would then use an enum with
specific
numerical values representing each OMPD version to bitshift or otherwise
represent
the version.
Is this a correct direction of thought?

>
> Jakub
>
>

Memory Handling

[y2s1982 via Gcc]

Hello Jakub,

Thank you very much for giving me a detailed instruction. I spent yesterday
studying the information over. I have few questions, and have also attached
a work-in-progress patch to confirm that I am heading the right direction.

On Tue, Jul 28, 2020 at 6:26 AM Jakub Jelinek  wrote:

> On Mon, Jul 27, 2020 at 01:59:01PM -0400, y2s1982 via Gcc-patches wrote:
> > I do know you have said this several times, and I thought I understood
> it,
> > but it seems I am wrong each time. I just want to clarify my
> understanding
> > and what I had intended on doing on this and would like further
> explanation
> > on what you would like to see happen more specifically so that I may make
> > less mistakes.
> >
> > My assumption in this patch was that, as the
> ompd_callback_symbol_addr_fn_t
> > callback function takes 2 context addresses and string query as input,
> and
> > ompd_address_t address as an output, I should give it:
> >   - the context addresses, which I assumed would contain a single data in
> > compact form generated from the tool's side having size, offset, and
> > address information,
> >   - and a string, which is basically a query that needs to be interpreted
> > by the callback function to determine which part of the data it needs to
> > use to generate to the returning pointer.
>
> The standard of course can't go into details on what exactly it is, because
> it is heavily dependent on what object format is used, etc.
> But for ELF, the intent is that the symbol addr callback does pretty much
> what dlsym does, i.e. perform a (dynamic) symbol lookup like the dynamic
> linker normally performs.  It likely can't use the dynamic linker directly,
> for running processes that would mean having to perform an inferior call to
> the libdl library, and for core files there is no running process to do it
> in, but it knows all the currently loaded libraries, their search order and
> so can in that order go one library by one and search their dynamic symbol
> tables (if you do nm -D on a library or readelf -Ws, you'll see what is in
> there), relocate the addresses in there for shared libraries depending on
> their load bias (difference between the addresses they are loaded at and
> linked to) and return those.  If filename is supplied, then it would
> perform
> the lookup primarily in the given shared library and only then fallback to
> others.
>
> > I wasn't sure what role the filename input played in this.
> > This seemed to fit what you meant by having a single compact data that
> > contains all the information while resolving my ongoing mystery as to
> what
> > the callback was expecting to have as the string identifying the symbol.
> To
> > further clarify, I assumed the callback would do string manipulation and
> > comparison to identify which information is being requested, refer to the
> > single data contained in appropriate context, and return the address
> > information.
> >
> > I am more than willing to scrap my bad idea for a better one. I am
> > sincerely interested in learning better ways to implement and improve
> > myself. I just need to know more specifics of the design, particularly:
> > - where the compact data is stored (I assumed context, which means it
> might
> > not be defined in the library side, but should it be in the handle or
> > global to library?),
> > - how the information necessary for the compact data is gathered (if it
> is
> > done on the library side, should I just use the ompd_callback_sizeof_fn_t
> > to obtain primitive sizes, and from there, just build the offset
> > information for each variable members? How about variable address?)
> > - how the ompd_callback_symbol_addr_fn_t callback function would likely
> use
> > it given its arguments (input of 2 contexts, 1 file name, 1 string to
> > output 1 address),
> > - what are the expected strings for the callback that would correspond to
> > each variable (here, I assume, the types would be gomp_thread,
> > gompd_thread_pool, gomp_team, etc.) or each member of said variables,
> > (these, at least I expected, should be documented and agreed on between
> > library and tool),
> > among other things.
>
> So, there are multiple things you might need to know about the libgomp
> shared library's internal ABI in order to implement the OMPD library that
> can handle it.
> One thing are addresses of internal variables.
>
> Say if OMPD wants to query the value of some ICV, those have different
> scopes, some of them are per-process, others per-device, others per-thread,
> others per-task.  Say the cancel-var is per process an