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

[y2s1982 .]

On Thu, Jul 2, 2020 at 11:12 AM Jakub Jelinek <jakub@redhat.com> 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