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