Adriaan van Os wrote:
So, why doesn't the linker optimize usage of libgpc routines (skipping unreferenced symbols) ?
Your "speculation" is correct.
[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".
Depends. It assumes some things about the code to optimize by symbols. I've seen code which jumps around in strange ways where this would break. Such code is probably not typical compiler output (but I guess producible using hand-coded `asm' statements), so it would at least have to be an optional feature. I don't know if there are more obstacles (i.e., the object code assumes the integrity of segments in some implicit way).
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.
Exactly.
One solution would be to put unit-initialization code in separate segments,
Wouldn't help much since it calls other routines.
a more drastic solution to put all groups of routines or even all routines in different segments.
Yes. C libraries achieve this by putting each function in a separate source file. For me, that's out of the question, since it makes the code hard to maintain and blows it up substantially (if only by the duplicated license notes, but also because many things need to be global which are unit-local now). I have rather strong opinions about this ...
However, there are the options `--function-sections' and `--data-sections'. While they alone don't seem to enable smart linking (at least wheen I tried it on Linux/IA32), they might allow processing of the object files using the binutils (objdump, objcopy) to split it into several files (and combine them into an `.a' archive). It should be possible to automate this, though it might not be exactly trivial to write an appropriate script to do so ...
Frank