Hi!
On Thu, 17 Jul 2014 14:58:04 +0200, I wrote:
> On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek <ja...@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 <tho...@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
pgpwIHYA7sCxi.pgp
Description: PGP signature
