> From: James E Wilson <[EMAIL PROTECTED]> > Date: Thu, 10 Mar 2005 21:51:12 -0800
> On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote: > > That question isn't applicable or maybe I should say "by > > identity mapping". To wit, SYMNAME refers to whatever has > > "static" in front of it *in the source code*, but for which you > > want it removed, i.e. globalized (speaking in C terms). > > I think you fail to appreciate the complexity of a compiler symbol > table. Perhaps, perhaps not. Right now, my interest is in defining the functionality seen by the user. > Particularly when GNU extensions are involved, and when > languages like C++ are involved. If you restrict yourself to ISO C, > then yes it will probably work in all cases. Otherwise, no, it won't. I don't really understand what you mean: if a thing is called "foo" in the source, then -fglobalize-symbol=foo would work. Naturally, the usability is restricted to the cases where the language has the distinction of a "local foo" and a "global foo", similar to C's static and non-static file-scope functions and variables. Another prerequisite is that other functionality (-fPIC) exists to override the symbol in another translation unit. Globalizing a C++ namespace, class or class member wouldn't work, for example. > You really should look at the #pragma redefine_extname and extern_prefix > documentation, FWIW I did look at that documentation. I did not see any particular applicable problems there. It seems you insist on this being a symbol-mapping modification, rather than a declaration modification. (If the "global" declaration or definition would be in error, well then emit an error. I don't see redefine_extname or extern_prefix interfering or being otherwise related - they don't apply to definitions local in the source!) > which lists a number of cases where this "by identify > mapping" concept doesn't work. I didn't see any that would apply to -fglobalize-symbol*, because the pragmas you mention apply only to external symbols (those declared in the source as external). An applicable example from the cases you see would help. Maybe this focus on the *generated symbols* is because I said "not a source-level modification" together with mentioning --wrap. I did mean "not a source-*code* modification". Sorry. Maybe the proposed option name had a part too. :-) All that just said for the record, because unfortunately due to yours and rth's negative reception of the proposal, I conclude that this feature does not currently have any chance of being accepted for FSF GCC. Oh, well. brgds, H-P
