> From: James E Wilson <[EMAIL PROTECTED]> > 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
