Frank Heckenbach wrote:
Adriaan van Os wrote:
I wonder if "ld" is an optimizing linker, as "nohello" has the same executable size as "hello".
That's interesting -- doesn't happen here. It might be the result of padding (though 600 bytes seems a little much), I don't know.
Maybe, a segment size of 1K or 2K or something like that. The "writeln" and "console" runtime library stuff will be linked in anyway, I guess, because of messages to standard error ?
I found that the default for the segment size is the system's page size (currently 4K on PowerPC).
BTW, is this GNU ld, or an Apple linker?
It's an Apple Mach-O linker. I will download the GNU linker to experiment with.
Still, there must be something wrong with or strange about libgpc.a. Have a look at this:
[G4:~/gnu/testgpc/adriaan] adriaan% cat empty.pas program empty;begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c -o empty.o empty.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o empty_automake empty.pas [G4:~/gnu/testgpc/adriaan] adriaan% set libpath = /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ [G4:~/gnu/testgpc/adriaan] adriaan% ld empty.o /usr/lib/crt1.o -L$libpath -lgpc -lgcc -lSystem -o empty_ld [G4:~/gnu/testgpc/adriaan] adriaan% ld empty.o /usr/lib/crt1.o -L$libpath -lgpc -lgcc -lSystem -all_load -o empty_ld_all [G4:~/gnu/testgpc/adriaan] adriaan% ls -l empty* -rw-r--r-- 1 adriaan staff 1956 Jan 29 22:41 empty.o -rw-r--r-- 1 adriaan staff 25 Jan 29 22:26 empty.pas -rwxr-xr-x 1 adriaan staff 682540 Jan 29 22:41 empty_automake -rwxr-xr-x 1 adriaan staff 682540 Jan 29 22:42 empty_ld -rwxr-xr-x 1 adriaan staff 971336 Jan 29 22:42 empty_ld_all
The hand-linked "empty_ld" has the same size as the autolinked "empty_automake". The executable "empty_ld_all" is larger, because it contains all symbols from the static libraries libgpc.a and libgcc.a (System is a dynamic lib).
Now, have a look at the symbol tables.
[G4:~/gnu/testgpc/adriaan] adriaan% nm empty_ld > empty_ld.sym.txt [G4:~/gnu/testgpc/adriaan] adriaan% nm empty_ld_all > empty_ld_all.sym.txt
If we compare both symbol tables in a text editor, we see that (1) both contain exactly the same number of _p_ entries (from libgpc.a) and (2) both contain a different number of entries from libgcc.a.
Conclusions (1) the linker does optimize usage of libgcc routines (2) the linker does not optimize usage of libgpc routines
So, why doesn't the linker optimize usage of libgpc routines (skipping unreferenced symbols) ?
[The rest of this email is more or less speculation. Please, correct me if I am wrong]
From reading "ld" docs, I got the impression that "ld" cannot optimize per Symbol, but only per Section in a Segment. If this is true, I consider it a grave limitation of "ld".
So, I hope I am wrong, but let's assume it is true. It implies that if only one Symbol in a Segment-Section is referenced, the whole Segment-Section will be linked in. Now, if we further assume that all code in a Pascal unit or module gets into one Segment-Section, including its initialization code (that always gets called) ..... all linker optimizations have automatically gone.
One solution would be to put unit-initialization code in separate segments, a more drastic solution to put all groups of routines or even all routines in different segments.
Regards,
Adriaan van Os