offload data version number

[Ilya Verbin]

On Fri, Jul 24, 2015 at 15:26:38 -0400, Nathan Sidwell wrote:
> this version makes the following changes to the earlier version.
> 
> *) Renames things to FOO_ver, rather than FOO_2
> 
> *) No attempt to deal with cross-version plugins and libgomp.
> 
> *) Adds GOMP_OFFLOAD_version function to plugin. (I went with your
> approach). Returns the GOMP_VERSION used to build the plugin, which
> libgomp checks matches the value for its build.  When we make
> incompatible changes to the plugin interface, that value can be
> incremented.
> 
> *) While working on gomp_load_plugin_for_device, I noticed the DLSYM
> and DLSYM_OPT macros were somewhat funky.  We're loading functions,
> so don't expect a NULL value.  We can simply check the returned
> value and only need dlerror when we get NULL.  The counting that
> DLSYM_OPT does was somewhat funky too.  IMHO better for that macro
> to simply return a truth value.

I do not know whether this is a good idea, but it's possible to add some magic
number into mkoffload:process () like:

865   fprintf (out, "static const void *target_data[] = {\n");
866   fprintf (out, "  MAGIC, VERSION, ptx_code, (void*) %u, var_mappings, (void*) %u, "
867                 "func_mappings\n", nvars, nfuncs);
868   fprintf (out, "};\n\n");

So, libgomp will be able to check target_data in GOMP_offload_register.
If MAGIC is present, it can check the VERSION, the plugin also can check the
version in a similar way.  This hack allows to avoid new versions of
GOMP_*_ver in libgomp and GOMP_OFFLOAD_*_ver in plugins.

  -- Ilya