Re: OpenACC Profiling Interface: 'acc_register_library' (was: OpenACC 2.5 Profiling Interface)

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, May 16, 2019 at 05:21:56PM +0200, Thomas Schwinge wrote:
> > Jakub, would you please especially review the non-OpenACC-specific
> > changes here, including the libgomp ABI changes?
> 
> Given a baseline that I've not yet posted ;-) would you please anyway
> have a look at the following changes?  Is it OK to add/handle the
> 'acc_register_library' symbol in this way?  The idea behind that one is
> that you dynamically (including via 'LD_PRELOAD') link your code against
> a "library" providing an implementation of 'acc_register_library', or
> even define it in your user code (see the test case below), and then upon
> initialization, "The OpenACC runtime will invoke 'acc_register_library',
> passing [...]".

Ugh, it is a mess (but then, seems OMPT has the same mess with
ompt_start_tool symbol).

It is nasty to call acc_register_library from initialization of the OpenMP
library, similarly to nastyness of calling ompt_start_tool from
initialization of the OpenACC library, neither of those symbols is reserved
to the implementation generally.
Can't we not do anything for -fopenacc or -fopenmp and have
-fopenacc-profile or -fopenmpt options that would link in another shared
library which just provides that symbol and calls it from its
initialization?  The dummy implementation would be __attribute__((weak))
and would dlsym (RTLD_NEXT, "...") and call that if it returns non-NULL,
so even if that library happens to be linked before whatever library
implements the user symbol.
Looking at what libomp does for ompt_start_tool, for Darwin they don't use
a weak symbol and instead just dlsym(RTLD_DEFAULT, "...") in the
library ctor, for Linux they have a weak definition that does dlsym
(RTLD_NEXT, "...") and for Windows use something yet different.

>     --- libgomp/libgomp.map
>     +++ libgomp/libgomp.map
>     @@ -469,6 +469,7 @@ OACC_2.5 {
>      	acc_prof_lookup;
>      	acc_prof_register;
>      	acc_prof_unregister;
>     +	acc_register_library;
>      	acc_update_device_async;
>      	acc_update_device_async_32_h_;
>      	acc_update_device_async_64_h_;

You certainly never want to add something to a symbol version
that has been shipped in a release compiler already.

	Jakub