From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11503 invoked by alias); 17 Jul 2014 14:37:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 11481 invoked by uid 89); 17 Jul 2014 14:37:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Jul 2014 14:37:04 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1X7mns-0000oh-AS from Thomas_Schwinge@mentor.com ; Thu, 17 Jul 2014 07:37:00 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jul 2014 07:37:00 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 17 Jul 2014 15:36:56 +0100 From: Thomas Schwinge To: Jakub Jelinek CC: Ilya Verbin , Kirill Yukhin , Richard Henderson , GCC Development , , Subject: Re: [RFC] Offloading Support in libgomp In-Reply-To: <20140717133536.GN31640@tucnak.redhat.com> References: <20130910151453.GB1817@tucnak.redhat.com> <20130910153053.GB2059@msticlxl57.ims.intel.com> <20130910153624.GD1817@tucnak.redhat.com> <20130910153810.GC2059@msticlxl57.ims.intel.com> <20130913112930.GC30181@msticlxl57.ims.intel.com> <87tx6go21t.fsf@kepler.schwinge.homeip.net> <20140717123712.GL31640@tucnak.redhat.com> <87ha2gnnvn.fsf@schwinge.name> <87lhrsnncj.fsf@kepler.schwinge.homeip.net> <20140717133536.GN31640@tucnak.redhat.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu) Date: Thu, 17 Jul 2014 14:37:00 -0000 Message-ID: <87egxknjay.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2014-07/txt/msg00173.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2977 Hi! On Thu, 17 Jul 2014 15:35:36 +0200, Jakub Jelinek 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 thi= s in > > > more detail.) > >=20 > > Heh, would a "hack" like the following work? > >=20 > > libcilkrts/runtime/sysdep-unix.c: > >=20 > > /* (Non-static) dummy function is used by get_runtime_path() to fin= d the path > > * to the .so containing the Cilk runtime. > > */ > > void dummy_function() { } > >=20=20=20=20=20 > > /* 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 =3D=3D dladdr(dummy_function, &info)) return "unknown"; > > return info.dli_fname; > > #endif > > } > >=20 > > 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? >=20 > 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=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTx9+FAAoJEK3/DN1sMFFtOGkH/1FZBsb4DMyZLFjPU8iMFOfb cLBXmNi76gyh7T93wPHSSCgN/Aq9ilBstUGvgPAHWqm2Go1Fb8eTRks+3xe9bGUA kITdnpi4OGrNPqKmt5cGaIrF4ThGFI2cHXyltx+AAYtWBcN3MH66ngsbogCKfdey f2jlXFxUBn6gIIYc0L/jIiCzIbQo1WQrCaKb9hGgNnqnLC5lOijJP93Rck48JX45 5EXigT1L7QjugbVSqeA4CMA4NhMe/A53TvzdoeFdkTw6vKHLS8bheIfXLNYxgE0q jxS6VyetdvOZiVTId/tWAzye1NLiQ2hufxMNnYQfIavwtEp5F5E3xHdAmOAivFs= =lFNT -----END PGP SIGNATURE----- --=-=-=--