On Fri, Jul 24, 2015 at 09:32:04AM -0400, Nathan Sidwell wrote:
> On 07/21/15 11:21, Nathan Sidwell wrote:
> >On 07/21/15 09:25, Nathan Sidwell wrote:
> >>This trunk patch implements new register and unregister entry points to 
> >>allow
> >>specifying data version information.  (I'll shortly be posting patches 
> >>changing
> >>the PTX offload data format.)
> >>
> >>We now have GOMP_offload_{,un}register_2, which take an additional unsigned 
> >>int
> >>version number.  The version number is composed of two parts.  16 bits for 
> >>the
> >>libgomp version and 16 bits for the device-specific plugin.  Currently both 
> >>are
> >>zero.  When the PTX data changes, that device-specific value will increment.
> >>
> >>The existing register/unregister calls forward to the new ones, providing 
> >>zero
> >>for the version information.
> >>
> >>On the plugin side I've added 2 new entry points 
> >>GOMP_OFFLOAD_{,un}load_image_2,
> >>which also take an additional version number argument.  These entry points 
> >>are
> >>optional, and only added to the PTX plugin.  The existing plugin entrypoints
> >>forward to the new ones.
> >>
> >>libgomp  will use these new entry points if they exist, otherwise use the
> >>original entry points, provided the incoming version is zero.
> >>
> >>I added the GOMP_offload_{,un}register_2 routines to the libgomp map file as
> >>version 4.0.2 -- I wasn't sure whether to increment it more than that. 
> >>Advice
> >>sought.
> >
> >this version is updated following committing the unload patch.  there were a 
> >few
> >(expected) collisions.
> 
> I committed a version to gomp4 branch, but would still like to get this to
> trunk ASAP.

So there is no version anywhere?  I remember in the design ideas the plan
was that the data section containing the target info (that originally has
been meant to be passed as GOMP_target parameter, but later on has been
changed to the register/unregister approach) will contain some header that
would include version number, some flags and details on the payload.
Do you mean that right now the data section (or pointer passed to the
register functions) only contains the raw bits (ELF DSO for Intel MIC and
PTX text files for NVPTX), rather than some header?
How do you determine the size of the bits?

In any case, I must say I don't like the GOMP_offload_{,un}register_2 names,
if they are really needed, then it should be GOMP_offload_{,un}register_ver
or something similar, _2 is just weird.
And I'd say that we don't really need to maintain support for mixing libgomp
from one GCC version and libgomp plugins from another version, worst case
there should be some GOMP_OFFLOAD_get_version function that libgomp could
use to verify it is talking to the right version of the plugin and
completely ignore it if it gives wrong version.

        Jakub

Reply via email to