Re: [RFC] Offloading Support in libgomp

[Thomas Schwinge <thomas@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 3009 bytes --]

Hi!

On Thu, 17 Jul 2014 15:35:36 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Jul 17, 2014 at 03:09:32PM +0200, Thomas Schwinge wrote:
> > > 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?
> 
> Well, libgomp has to be far more portable than this, so the question is
> if we want to live with one behavior on Linux and another one elsewhere
> (fallback to absolute path)?

Hmm, that doesn't really seem appealing.

> In any case, as last resort it should just try
> to dlopen the plugin without full path, and the plugins really should have
> libgomp-plugin or something similar in their names to make it less likely
> to clash with something else.

The problem is that we don't know the plugins' names.  Currently, we're
scanning a directory for all filenames matching libgomp-plugin-*.so.1.

> If we would be ok with that, then a function to return that would need
> to go into config/linux/ and config/posix/.

(config/gnu/ instead of config/linux/, as that's more a GNU/glibc thing
than a Linux kernel thing.)

Hmm, take one step back.  Putting the plusing next to libgomp.so will
make their discovery easy, as that'll be governed by the very same
searching rules that led the dynamic linker to libgomp.so.  All plugins
are named libgomp-plugin-*.so.1.  But we'd have to know the plugins'
names (for use with dlopen), losing the ability to dynamically extend the
set of libgomp plugins.  This in turn could be achieved by setting an
environment variable that specifies an additional -- or replacement? --
directory to scan, or even just specifies a list of additional plugin
*names* to load, again relying on the standard searching rules for them
to be found.  Is that a reasonable price to pay?


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]