On 12/04/15 20:51, Ard Biesheuvel wrote: > On 4 December 2015 at 20:20, Daryl McDaniel <[email protected]> > wrote: > [...] >>> On 12/03/15 13:54, Ard Biesheuvel wrote: >>>> The default behavior of the GCC compiler is to emit uninitialized >>>> globals into a COMMON section, where duplicate definitions are merged. >>>> This may result in unexpected behavior, since global variables appearing >>>> by the same name in different C files typically do not refer to the same >>>> conceptual data item. >> >> If the files are being linked together, then this is exactly the correct >> behavior.
I missed this paragraph in my previous reply, sorry about that. It is not the right behavior to merge duplicate *definitions*. A *definition* causes storage to be allocated for the object, per translation unit in isolation, and according to the standard, as long as the object is used in a non-sizeof expression in the program, the entire program must do that allocation exactly once (= in exactly one translation unit). No merging. *Declarations* (in the style of "extern int x;") can exist in as many instances as the programmer feels like. They don't allocate storage. Tentative definitions turn into external *definitions*, not declarations. In one sentence, no header file must say "int x;" -- they all must say "extern int x;", and the tentative definition "int x;" must be moved to a single C file. >> If the variables do not refer to the "same conceptual data item" >> then they either have to be renamed or made static. > > Indeed. This remains true regardless of whether we use -fno-common or > not, and the only difference is that we will flag them rather than let > the compiler silently merge them. I fully agree. > And if no instances remain that are > intended uses of COMMON behavior, it no longer matters whether we pass > -fno-common or not. > >> This is a common problem when combining code that comes from multiple >> unrelated sources. Checking for this type of name collision should be part >> of the porting process. The name collision should be caught by the linker at build time, not when the driver or application is run, and also not by textual search while porting. For example, when global variables are created with token pasting ##, textual search may have no chance at finding the preexistent variable. Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
