gcc-patches@gcc.gnu.org
[Top] [All Lists]

Re: forcing most functions of libiberty in plugin-enabled cc1

Subject: Re: forcing most functions of libiberty in plugin-enabled cc1
From: Basile STARYNKEVITCH
Date: Fri, 27 Nov 2009 08:19:58 +0100
H.J. Lu wrote:
On Thu, Nov 26, 2009
What won't work is to install libiberty.so but still have cc1 linking the
static libiberty.a, as explained in
http://gcc.gnu.org/ml/gcc/2009-07/msg00166.html

So what did you (H.J.Lu) meant by "install libiberty for the plugin"?


You can install libiberty.so without linking it against cc1 while your
plugin can link against libiberty.so if needed.

It won't work, in particular for libiberty functions having static data, which 
are already linked inside cc1.
Take for example make_temp_file in libiberty/make-temp-file.c. This is a function I would like to access from plugins. In MELT plugin, I had to code a function for temporary files without it.

make_temp_file uses a static variable memoized_tmpdir (line 91 of 
libiberty/make-temp-file.c).

If it where linked both in cc1 statically and in libiberty.so from a plugin, we 
would have two instances of the
make_temp_file function, each using their own memoized_tmpdir.

Likewise, a random number generator (like the one in libiberty/random.c) would behave wrongly if linked statically from cc1 and also dynamically from a plugin: the random numbers used by cc1 will be correlated to the ones used by the plugin.

We *really* need most libiberty functions linked inside cc1. For MELT, I am particularily concerned with xstrndup (which does not appear in cc1 the last time I checked in ocotber 2009), pex_init, pex_run, pex_get_status and friends (I had to use system(3) in melt.so, and that means doing all the dirty work of escaping spaces & other charaters in program arguments), and make_temp_file.

My point is that we really should settle this issue before 4.5 release. Should 
I open a PR?

And besides, I believe that for newbies coding plugins, we have an incoherent talk: we are saying: hey, we have a libiberty to solve your portability issues, but you should not use it in your plugins. They will rightly langth at us.

libierty should be fully usable from plugins. And that means it should either be entirely linked into cc1 (as my dirty patch proposed), or that cc1 should link dynamically, when plugins are enabled, a libiberty.so.

Regards.
--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

<Prev in Thread] Current Thread [Next in Thread>