Re: [PATCH] removal of "static foo = 0"

[Michael Meissner <meissner@spectacle-pond.org>]

On Mon, Nov 27, 2000 at 10:35:45PM -0500, Alexander Viro wrote:
> 
> 
> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
> 
> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, kumon@flab.fujitsu.co.jp wrote:
> > > If you have two files:
> > > test1.c:
> > > int a,b,c;
> > > 
> > > test2.c:
> > > int a,c;
> > > 
> > > Which is _stronger_?
> > 
> > Those won't link together as they aren't declared static.
> 
> Try it. They _will_ link together.

This is a GCC extension (actually it is a pretty common UNIX extension, but the
official standard says you can only have one definition of a global variable).

Off the top of my head, here are some reasons variables could be put in
different orders:

   1)	The compilation system has the concept of a small data pointer, which
	is a register that is assumed by the compiler to point to a small
	region of memory (it is never allocated by the compiler and setup in
	the initialization modules).  The compiler decides to put some
	variables into the small data region and other variables outside of
	it.  Typically the choice is based on size of the variable.  Small data
	pointers are typically used when the machine has plenty of registers
	and it takes 2 or more instructions to build the address of a random
	variable in memory with load high/load low type instructions, and the
	small data pointer has the upper half already loaded, and uses special
	relocations to access the variable based off of the difference of a
	special symbol.

   2)	Even without a small data pointer, a compiler might decide to sort the
	variables emitted based on either size or number of accesses to take
	advantage of instructions with smaller offsets.

   3)	The above mentioned global, non-initialized variables (ie, the
	so-called 'common' variables).  Where the linker puts the variables
	into the bss section in any order it chooses.  For example, the VMS
	linker used to sort common variables alphabetically.

   4)	For static variables, the compilation system might decide to omit the
	variable until it sees a reference to the variable, and if the first
	variable is referenced in one function, and the second is referenced
	several functions later.

   5)	At some point in the future, on machines with many more registers than
	the normal 32, the linker might see all references to a variable, and
	decide to put it in a static register rather than memory.

   6)	A checkout compiler could randomly order things specifically to catch
	these type of errors (the problem with the normal checkout compilers
	that I'm aware of, is that the kernel uses structs to talk to real
	devices and interact with system calls with fixed layouts).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/