retard wrote:
To me it feels like a modern linker is more a simple compiler than a
'cat' utility.
That may be true if the linker is doing JITting or some such, but
Optlink and ld do nothing like that and do not do anything resembling
what a compiler does.
One could argue that also the compiler is a huge
concatenation system which concatenates "sections" (statements and
expressions) and produces executable code for the linker.
That is not a useful mental model of what a compiler does. I'm trying to
impart a mental model of what the linker does that is useful in that it
makes sense of what goes in the linker and what comes out of it.
My linker of
choice has a frontend for the scripting language, several translation
engines to convert between object file formats, byte orders etc. It also
does optimization and modifies executable code & symbol names when needed/
asked. It does kind of conditional compilation since I can pack many
versions of the same code in to the executable. In addition linker can do
stuff like code injection and link time evaluation (even ld can do that).
No wonder you're confused about what a linker does! Yes, some linkers do
those things. No, they are NOT the prime thing that it does. The prime
thing a linker does is concatenate blocks of data together and write
them out.
Controlling the order of those sections, dealing with byte orders, file
formats, etc., is all detail.
At its core, you could conceivably design an object format and have the
linker *actually* just concatenate those files to form an executable.
The original MS-DOS executable file format wasn't even a file format, it
was nothing more than binary data that was copied into memory and
blindly jumped to.
I've been using *nix since I learned to read. I couldn't be more
interested in legacy cp/m or m$ crap.
I think early executable formats for unix (and other machines of that
day) were pretty much the same. Over time, complexity got layered on,
but the fundamentals never changed.
The man page only shows a basic set of switches to use the linker. In
reality you need lots of other documentation just to write linker scripts
or when writing operating systems or programs for embedded platforms.
You don't need to know any of that to figure out what is consuming space
in your exe file.
(BTW, exe files for embedded systems tend to be nothing more than binary
data to be blown into EPROMs - blindly jumped to by the microprocessor.)