On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> I don't really understand what you mean: if a thing is called
> "foo" in the source, then -fglobalize-symbol=foo would work.
My main concern is that we have a long history of adding flawed features
that have to be later removed. So I want you to try to think about
anything that might possibly go wrong now instead of just assuming that
it will obviously work. You are proposing a new kind of option, one
that first translates symbolnames to variable names, and then changes
their linkage, so you need to carefully define exactly how this works in
all cases, and how it interacts with all existing gcc features.
I thought looking at the existing pragmas was a good start, as they
already have support for mapping a symbolname to a variable. You are
right that these work on external names not statics, and hence aren't
completely relevant. That is a mistake on my part. They do mention the
C++ extern "C" {} limitation which does apply here. There may or may
not be anything else useful there.
The original poster mentioned an interaction with .hidden, so you need
to define how the feature of removing static interacts with visibility
attributes.
There may also be other issues that need to be dealt with. It would be
useful to browse the C standard and the list of gcc extensions to look
for possible issues that might need to be dealt with. It may also be
useful to look at how gcc internals handle static and look for potential
problems.
I am not opposed to the feature in principle. I just think that you
aren't being vigorous enough in defining it. I'd like to see a formal
specification of what the option does, both in how the symbolname to
variable mapping works, and in how the static removal works. A
carefully written implementation and carefully written documentation
would probably be sufficient, as we generally don't do formal
specifications here. Again, I think the pragmas are a useful reference
here, as you can see the amount of care that was taken to try to define
the meaning of every possible interaction with other gcc features both
in the documentation, and in the source.
Richard however does appear to be objecting in principle, which is
another matter.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
