From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78126 invoked by alias); 24 Jul 2015 16:35:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 78106 invoked by uid 89); 24 Jul 2015 16:35:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f178.google.com Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 24 Jul 2015 16:35:16 +0000 Received: by wibud3 with SMTP id ud3so35170846wib.0 for ; Fri, 24 Jul 2015 09:35:13 -0700 (PDT) X-Received: by 10.194.23.225 with SMTP id p1mr30506209wjf.155.1437755713371; Fri, 24 Jul 2015 09:35:13 -0700 (PDT) Received: from msticlxl57.ims.intel.com ([192.55.54.42]) by smtp.gmail.com with ESMTPSA id jr5sm9328221wjc.14.2015.07.24.09.35.10 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Jul 2015 09:35:12 -0700 (PDT) Date: Fri, 24 Jul 2015 16:46:00 -0000 From: Ilya Verbin To: Jakub Jelinek Cc: Nathan Sidwell , ilya.verbin@intel.com, GCC Patches Subject: Re: offload data version number Message-ID: <20150724163504.GC41292@msticlxl57.ims.intel.com> References: <55AE483D.9050702@acm.org> <55AE637A.8040504@acm.org> <55B23E54.4070504@acm.org> <20150724163016.GT1780@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150724163016.GT1780@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg02089.txt.bz2 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