> From: James E Wilson <[EMAIL PROTECTED]> > Date: Thu, 10 Mar 2005 19:34:01 -0800
> On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote: > > 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. I'm referring to the name *that appears in the source code*. Not the symbol at the assembly level. > So when an option mentions a symbol name, exactly how do we find the > variable that matches that symbol name? 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). > 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. No, the "hence" doesn't necessary follow: your argument assumes that --wrap is the only way to use -fglobalize-symbol=SYMNAME. It is true that --wrap isn't generally usable for anything but C (or simple source-to-assembly-mapping) for the reasons you mention but that's nothing new. I mentioned --wrap just as *one* way of modifying SYMNAME later on (so please don't get stuck on it): -fglobalize-symbol=SYM would still be usable without it, for example compile the code with -fpic, make a DSO out of it and override SYMNAME in another DSO or the executable. No need to know mangling there. If there was use of redefine_extname or asm to define SYMNAME at the assembly-level name, it better be used in the overriding code as well. brgds, H-P
