This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Feature request: Globalize symbol
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: wilson at specifixinc dot com
- Cc: fredrik dot hugosson at axis dot com, gcc at gcc dot gnu dot org
- Date: Fri, 11 Mar 2005 01:55:08 +0100
- Subject: Re: Feature request: Globalize symbol
> Date: Thu, 10 Mar 2005 14:41:23 -0800
> From: James E Wilson <wilson@specifixinc.com>
> Fredrik Hugosson wrote:
> > My proposal is the following new options:
> > -fglobalize-symbol=SYMBOLNAME
> > -fglobalize-symbols=FILENAME
> > -fglobalize-all-symbols
>
> It is unlikely someone will volunteer to implement a feature that only
> you need.
On the other hand, this is a future that seems likely to be of
use to others, and it's likely that I'll help implement it, if
the usability and other details are agreed upon.
> Globalizing a symbol in a shared library is potentially unsafe, and that
> may resulting in linker conflicts, or it may result in a shared library
> variable being overriden by a variable in another module causing silent
> changes in behaviour.
I think you misunderstood. The suggested feature is for
*non-source-intrusive instrumentation* only. The goal is to
make static-declared functions and variables in file scope to be
global, not static, so they *can* be overridden elsewhere and/or
renamed through the GNU linker "--wrap" feature.
Perhaps it is better described that -fglobalize-all-symbols
would be equivalent to "#define static" when there are no
function-scope statics. I'm told there are no known way to
accomplish this by other means. Of course the user of that
option must know that no (unintended) symbol conflicts occur.
> Another way to attack this problem would be to add accessor functions to
> the shared libraries.
But that requires source-level instrumentation.
brgds, H-P