On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote: > This isn't a source-level modification, by definition.
And I could argue that my suggestion isn't a source-level modification either, or I could argue that your suggestion really is a source-level modification, but it seems pointless to argue about this. Certainly, a gcc option is more convenient, if someone is willing to volunteer to implement it. > Of course! The simple (and best) way out is to define what > happens in all those situations as the equivalent of removing > "static" for such an identifier in file scope I think you missed my point. The proposed -fglobalize-symbol=SYMNAME option assumes that it is obvious what a variable's symbol name is. Variables often have different names in the input source file and the output object file. Also, variables can sometimes have multiple names in the input source file. This may depend on gcc extensions being used. Or in a language like C++, it may depend on the context that the variable is declared in, e.g. namespaces, class contexts, template expansion, etc. So when an option mentions a symbol name, exactly how do we find the variable that matches that symbol name? But it looks like we have solved this problem before, because we have pragmas that take symbol names. See the comments in c-pragma.c for #pragma redefine_extname. The next question then is whether the proposed option is still useful if we have to apply all of the same restrictions that #pragma redefine_extname requires. Also, there is still the question of how this gets used for instrumentation. For instance, you mentioned that you want to use linker wrapping, but the linker wrapping would have to use the assembler name of the symbol which can be arbitrarily different from the source level variable name. So you need two possibly very different symbol names for the -fglobalize-symbol and --wrap options, and there is no foolproof way for the external unit tester to know the mapping between the -fglobalize-symbol DECL_NAME and the --wrap options DECL_ASSEMBLER_NAME. Of course, this won't be a problem in the common case for ordinary C global variables, but it does mean that the unit tester won't be able to handle all cases. Hence this may not be the best approach to solve the general problem of unit testing. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
