offload data version number

[Ilya Verbin]

On Fri, Jul 24, 2015 at 18:30:16 +0200, Jakub Jelinek wrote:
> 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?

Yes, currently there is no version in target info, which is passed to register
function.  In case of MIC, this header contains only 2 fields: start and end of
the target image.

  -- Ilya