🚀 go-pugleaf

	Just an armchair opinion, but from someone who did once have his
fingers in GCC (up to 1.40). It is a bit long, but if you want an informed
guess about _why_ this is occuring, read on:

Richard G. Hash (rgh@shell.com) wrote:
: In <CxB81o.IEt@beaver.cs.washington.edu> jdean@bergen.cs.washington.edu
  (Jeffrey Dean) writes:
: > Linking compiler
: > 0706-781 ERROR: TOC overflow. TOC size: 647000  Max size: 65536
: > collect2: ld returned 12 exit status

: >   a) Does anyone know how to increase this limit or work around it?

: From an fax IBM sent me:
:     From a source code point of view, TOC entries are used by:
:       - each unique FORTRAN named or common uses 1 entry
:       - each reference to a C global (extern) variable

	If this is a "literal pool" problem, I can't help, but if, as
suggested by the reference to FORTAN named common it is a more usual
"feature", read on. Early C compilers used what was called the "common
model" for variable. In this model, several files can all contain the
declaration:

int fred;

and they will all be resolved to a single instance of the actual storage
for "fred" (typically 2-4 bytes) by the linker. The way this is usually
kluged is to either use a *nix-style linker or put each variable in a
separate "section" exactly equivalent to FORTRAN common. The problems are:

	1) there is no way to distinguish (at the object code level)
	   between "int fred" and "extern int fred", which can lead
	   to some interesting debug sessions when one of the files
	   is mis-typed "int ferd" :-)

	2) There can be no knowledge, even in the file which declares
	   "int fred", of its address relative to any other variable,
	   eliminating the possible use of "pointer+displacment"
	   addressing even in the "owner" file. This is because the
	   compiler can never know that a given file _does_ own
	   the variable.

In the more traditional (and I believe recomennded by ANSI C) "def-ref" model:

extern int fred;

means "there is somewhere a variable named fred, but I am not sure where yet",
like "int fred" does in the common model, except that the linker can warn
you when nobody says "int fred" rather than silently incarnating a bogus
variable for each typo :-) But:

int fred;

means "I am hearby reserving the space for fred and nobody else will, so
if you can use that information, go for it". It also means that the file
with "extern int ferd" can be caught by the linker, rather than a totally
frazzled programmer after a fair amount of debug time.

	Anyway, although "def-ref" is the "standard", many compilers,
including "out of the box" GCC (as far as I know) still use the old
"common", model to avoid ticking off folks who want to compile "dusty
floppy" code and just couldn't bring themselves to type "extern" back
in 1970. The "fix" for my copy of the 68K version of GCC 1.* was fairly
simple, and involves two definitions in tm.h. I would just post it, except
that it will not be the "total solution" in your case. I made the change
for enhanced debugging, not to save on address literal pool, which the 68K
does not use. If I had the time and energy, I could probably squeeze some
performance out of it by using "pointer+disp" addressing, but I'm lazy :-)

	In your case the change _might_ help, or might not. I am fairly
certain from the following:

:       - each static area in a compilation unit uses 1 entry
:         (all static variables uses only 1 entry)

	That the compiler _could_ make intelligent use of def-ref (since
it would be logically equivalent to making the variable static in the
"owning" file), but I'd doubt it does.

	To further muddy the waters, these :

:       - each local function call that exceeds 64K in branch distance
:       - each external function call
:       - each C function pointer definition

imply that it is indeed an address-literal-pool problem.

: >   c) Are there flags for gcc that will cause it to not put certain
: >      things in the TOC, similar to the -qdatalocal for IBM's xlc compiler?
: >      If so, this might reduce the size of the TOC (although it's unlikely
: >      to cut it by an order of magnitude, I suppose).

	Perhaps the "minimal-toc" switch referenced in a later post will
help, and does some or all of this, bit it's a stretch.

	A suggestion from early days trying to squeeze perfromance out of
slow 68K systems, is to, where possible, group the all the variables a file
uses into one seriously ugly struct. When spoon-fed this way, the compiler
will often use the (shorter and faster) "pointer+disp" addressing, and
it would be bound to reduce the number of addresses needed.

	BTW: If this program is getting into this mess by really having that
many distinct global _variables_ around, it is probably beyond the scope
of anybody to maintain anyway, time for a re-write :-)

	The whole reason I posted this rather long-winded followup to
comp.arch was to elicit comments on how often this sort of thing (dusty-
deck coding standards meet "seemed like a good idea at the time" CPU
constraints) happens to other folks.

					Mike
| Mike Albaugh (albaugh@agames.com)
| Atari Games Corp (Arcade Games, soon to be Time Warner Interactive)
| 675 Sycamore Dr. Milpitas, CA 95035		voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)