Hi Jakub,
Thanks for the explanation, it's getting a bit clearer, though I still have some
questions.
> __OPENMP_TARGET__ would be a linker plugin inserted symbol at the start of
> some linker plugin created data section, which would start with some header
> and then data.
> Say
> uleb128 number_of_supported_targets - n
> uleb128 number_of_host_var_pairs - m
> [ name of offload target (asciiz?)
> relative offset to the start of the offload data for the target (in MIC
> case embedded DSO)
> size of the offload data
> perhaps something how to find the target addresses array
> ] repeated n times
> [ host_address, size ] repeated m times
> (for the functions passed to GOMP_target the pair would be [
> foobar.omp_fn.25, 1 ] ).
So, in this table we store host addresses of global variables, marked with
'pragma omp declare target', and addresses of host-versions of OMP-versioned
functions. Correct? Also, there are pointers to images of target-binaries,
which are (presumably) placed in other (or the same?) data sections.
> So, when GOMP_target{,_data,_update} is called, it could easily determine
> if the calling shared library resp. binary has been offloaded or not
That's right.
Then, if no initialization has been performed yet, GOMP_target{,_data,_update}
is initialized. Now let's look at the initialization.
In initialization GOMP_target* looks at the __OPENMP_TARGET__ table (its address
is passed as the 3rd argument), finds pointer to a data section with
target-binary image, loads it to memory, runs a process on a target from it
(e.g. in COI using COIProcessCreateFromFile and/or
COIProcessLoadLibraryFromMemory).
Global variables are mapped and the corresponding host<->target address pairs
are inserted to the splay tree, as usual.
Also, GOMP_target* should do the same for function addresses. Could you please
describe this step in more details? Do we want to just add some offset to
host_function_address (as we want host versions of functions to be ordered
exactly as the target versions)?
> See above, names are just a bad idea. You can just use some magic wrapper
> name in the target binary (the one sitting in libgomp), to which you just
> pass the pair of function address and it's argument and the named function
> will just read the (target) function pointer and (target) pointer argument
> from misc data block and tail call that function.
Yes, if we know target function pointer, we can do this.
Basically, the main question I have now is how would we figure out target
function address? Of course, after initialization we just look for it in our
splay tree, so the question relates to the initialization step.
Thanks, Michael
