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