Re: Feature request: Globalize symbol

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> From: James E Wilson <wilson@specifixinc.com>
> Date: Fri, 11 Mar 2005 17:52:03 -0800

> 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.

That describes some GCC extensions rather than features invoked
by explicit options, IIRC.

>  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.

In general, those are my concerns too.  But we're not at the
stage when precise definition is called for: I wanted to get
initial reaction.  That was negative.  Further discussion is
academic.

>  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.

The proposal is an instrumentation feature that is explicitly
invoked, not a GCC extension that can appear anywhere in the
source.  For such a feature, I think it would (for example) be
enough to define a domain where the feature works, and declare
everything else a (possibly undetected) error.

> The original poster mentioned an interaction with .hidden, so you need
> to define how the feature of removing static interacts with visibility
> attributes.

Yes, I asked Hugo to describe interaction of the feature with
the visibility attribute.  Unfortunately that was not defined in
the necessarily explicit terms in the proposal.  Fortunately, no
intricate rules are needed: visibility attributes do not appear
on things declared static.  (They are ignored with a warning;
best would be to force the "default" visibility when the option
is in effect, with or without the current warning.)

> 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.

Good implementation advice.

> I am not opposed to the feature in principle.

Thanks.  This is the level of answer I actually was looking for.

>  I just think that you
> aren't being vigorous enough in defining it.

I am not defining it.  You're too vigorous trying to make me do
that at this time.

My intention was to correct misunderstandings about what the
feature was *intended* to do.  This in order to get informed
feedback whether this feature would be acceptable for FSF GCC.
It seems in doing that, I have been dragged into discussion
about a formal precise definition of the feature.  That's
premature.

I would of course look into neighboring areas and options if I
would implement this.  Right now, I think that will not happen.

I do know of the getting-detailed-definitions-of-GCC-extensions
problem; please assume I have the same basic concerns as anyone
here.  Really no need to reiterate on that.

(Any/All: If you now want to discuss whether a full
implementation, specification and documentation *must* be
present in order to get an *initial* reaction on a GCC feature,
please change the subject.  Please.)

>  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.

In due time.  Having said all that, the intended main effect
would be the equivalent of "#define static" (or "-Dstatic=") in
C when there are only file-scope statics (i.e. not affecting
function-level statics).  That's all at the moment.  Everything
else is corner cases and side-effects; details to be defined.

> Richard however does appear to be objecting in principle, which is
> another matter.

Alas.  Still, that answer was at the "right" level for me at
this time.  I have to discuss this with Hugo when he's back
from vacation.

brgds, H-P