[OMPD] Questions on per-process functions and related data types.
Thu Jul 2 22:58:49 GMT 2020
On Thu, Jul 2, 2020 at 11:12 AM Jakub Jelinek <firstname.lastname@example.org> 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
> > > debugger to make assumptions on what exactly it points to
> > > (similarly how e.g. with the context handles which are again pointers
> > > 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
> > to define
> > them. Is it okay to define the handle? Also, is the context only stored
> 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
> 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
> freed by OMPD.
This is giving me more clarity on what I have to do. At the moment, I am
information in the handle.
I do have one problem: in 188.8.131.52 (
it states that the call may verify the version compatibility using the
How should I handle this?
The version compatibility is something I am also struggling with. I don't
the higher version is backward compat with all earlier versions or like
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
created the handle before passing in the address to its own pointer. I
will check for NULL.
More information about the Gcc