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: Thu, 26 Nov 2009 20:18:18 +0100
Basile STARYNKEVITCH wrote:
Richard Guenther wrote:
On Wed, Nov 25, 2009 at 4:47 PM, Basile STARYNKEVITCH
<basile@xxxxxxxxxxxxxxxxx> wrote:
Hello All,

A plugin using a function in libiberty like make_temp_file fail to be
dlopen-ed, because cc1 don't have it.

We did discuss in
  http://gcc.gnu.org/ml/gcc/2009-07/msg00166.html &
  http://gcc.gnu.org/ml/gcc/2009-07/msg00157.html
the usefulness of linking all (or at least most of) libliberty.a inside cc1
for plugin usage.

This is completely broken.  Instead link libiberty.a with --whole-archive
when plugins are enabled.


That won't work on non-binutils systems (AFAIK --whole-archive is a binutils options to the linker), and the point of libiberty is precisely to provide a portability layer.
http://gcc.gnu.org/ml/gcc/2009-07/msg00174.html
http://gcc.gnu.org/ml/gcc/2009-07/msg00175.html

I do agree that the patch is quick & dirty. But:

 * it is portable AFAIK (since they is no language tricks)

 * it should work on any (even obscure) plateform

* the only thing impacted is the resulting cc1 binary size. No additionnal code is executed!

I would like some comments by people familiar with non-linux systems (and systems whose linkers is not the binutils one) providing a dlopen. Of course, if we only targeted linux (which I would be happy with) the proposed patch is crap.


The more I am thinking about it, the more I feel the patch is serious and 
should be considered by reviewers.

Of course, there may be more elegant ways of solving the issue that the patch 
try to solve. However,

1. We could decide (in my opinion that would be a big mistake) that libiberty is not usable by plugins. If we do decide that, we should at least document that fact seriously in plugins.texi. My opinion is that, since libiberty is a portability wrapper, it should be available to plugins. Otherwise I don't see the point of having it in systemes (like Linux) which don't require most of it.

2. Otherwise, libiberty should be usable by plugin. My patch is indeed quite ugly, but I would believe it have the same virtue as libiberty: it should be highly portable (because I believe it is quite standard C), and I believe it is the only way of achieving easily that goal. If some has some ideas for making libiberty available to plugins, particularily on non-linux systems, I would be delighted.

The answer use --whole-archive is not adequate, unless the --whole-archive option is available on every system on which GCC wants to permit plugins. If that is the case (I really don't know), then we should *force* that option, or any other way of making libiberty available, into the GCC core! This probably means a Makefile.in patch at least, and probably a configure.ac patch also.

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>