On 07/24/15 12:30, Jakub Jelinek wrote:
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?
There is no header information in the target data. Certainly for PTX, and
AFAICT for intel mic too. One cannot tell the format (or size) of the data
just by looking at it.
I had thought about adding such a header, but that would be problematic in
forwarding from the unversioned entry points to the versioned ones.
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.
sure, I'm not very imaginative with names :)
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.
Ok, I wondered about making such an assumption. Implementation-wise, I don't
think another entry point's needed. libgomp can observe the register_2 entry
point and that contains the smarts to check the incoming 2-part version number
from the target data. I'm pretty sure that'll be sufficient.
thanks for the review. will work on updating patch.
nathan
