Hi!

On Thu, 17 Jul 2014 14:58:04 +0200, I wrote:
> On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> > > 2014-07-17 11:51 GMT+04:00 Thomas Schwinge <thomas@codesourcery.com>:
> > > >> +  plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> > > >
> > > > What is the benefit of making this an environment variable that the user
> > > > set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> > > > somewhere inside the GCC installation directory ([...]/lib/libgomp/*.so)?
> > > > (There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH, and
> > > > LD_LIBRARY_PATH.)  Hard-coding it would make libgomp testing a bit
> > > > easier, and it generally seems to make sense to me that the compiler
> > > > (libgomp) should be able to locate its own resources, and I don't think
> > > > the plugin search path is something that a user generally would want to
> > > > override -- or is your use case indeed that the plugin is not built as
> > > > part of libgomp's build process?  (But, in this case you still could use
> > > > LD_LIBRARY_PATH to have it found.)
> > > 
> > > We invented this environment variable almost a year ago, when we
> > > didn’t fully understand how all the parts will work together. So for
> > > now, likely, your proposal is better.
> > > Jakub, what do you think?
> > 
> > Yeah, certainly.  Though, ideally the path it looks at should be relative
> > to the directory where libgomp is installed
> 
> Right...
> 
> > and I'm afraid it is hard to
> > figure out portably where it was loaded from, and DT_RPATH/DT_RUNPATH on
> > libgomp would affect all dlopen calls, not just the loading of the plugins.
> > Not sure if one can use at least on Linux ${ORIGIN} in dlopen and what
> > exactly will it expand to.
> 
> I haven't verified, but I'd guess it to expand to the *executable*
> linking against libgomp, so that won't help...
> 
> I have, however, found some logic in gcc/plugin.c that seems at least
> similar to what we need:
> 
> gcc/doc/plugins.texi:
> 
>     @node Plugins loading
>     @section Loading Plugins
>     
>     Plugins are supported on platforms that support @option{-ldl
>     -rdynamic}.  They are loaded by the compiler using @code{dlopen}
>     and invoked at pre-determined locations in the compilation
>     process.
>     
>     Plugins are loaded with
>     
>     @option{-fplugin=/path/to/@var{name}.so} [...]
>     
>     [...]
>     
>     A plugin can be simply given by its short name (no dots or
>     slashes). When simply passing @option{-fplugin=@var{name}}, the plugin is
>     loaded from the @file{plugin} directory, so @option{-fplugin=@var{name}} is
>     the same as @option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so},
>     using backquote shell syntax to query the @file{plugin} directory.
> 
> gcc/plugin.c:
> 
>     /* Retrieve the default plugin directory.  The gcc driver should have passed
>        it as -iplugindir <dir> to the cc1 program, and it is queriable through the
>        -print-file-name=plugin option to gcc.  */
>     const char*
>     default_plugin_dir_name (void)
>     {
>       if (!plugindir_string)
>         fatal_error ("-iplugindir <dir> option not passed from the gcc driver");
>       return plugindir_string;
>     }
> 
> But I'm not yet sure how we could use this to tie the libgomp plugin
> search path to the location of libgomp.so...  Especially, given that the
> location of libgomp.so during compilation need not match the location
> during execution.  A show-stopper?  (No time currently to explore this in
> more detail.)

Heh, would a "hack" like the following work?

libcilkrts/runtime/sysdep-unix.c:

    /* (Non-static) dummy function is used by get_runtime_path() to find the path
     * to the .so containing the Cilk runtime.
     */
    void dummy_function() { }
    
    /* return a string with the path to the Cilk runtime, or "unknown" if the path
     * cannot be determined.
     */
    static const char *get_runtime_path ()
    {
    #ifdef __CYGWIN__
        // Cygwin doesn't support dladdr, which sucks
        return "unknown";
    #else
        Dl_info info;
        if (0 == dladdr(dummy_function, &info)) return "unknown";
        return info.dli_fname;
    #endif
    }

Putting that into libgomp, it should give the path to the libgomp.so
actually loaded, and then we can load the plugins relative from its
dirname?


Grüße,
 Thomas