Compiler: Size of generated executable file

retard re at tard.com.invalid
Mon Jan 11 02:24:04 PST 2010


Mon, 11 Jan 2010 00:54:24 -0800, Walter Bright wrote:

> retard wrote:
>>> The file formats are complicated. The concept of what the linker does
>>> is trivial, especially when we're talking about "what consumes space
>>> in the exe file".
>> 
>> If you take for example GNU ld from binutils, it's not that trivial. It
>> even has its own scripting language. If the object file format is
>> complicated, the linker has to support most important parts of the
>> spec, at least. ld happens to support several architectures, several
>> operating systems, several language mangling conventions, and several
>> object file formats. The architecture has pluggable components and it
>> comes with tons of switches for various kinds of tuning options. As a
>> whole, it takes couple of weeks of intensive learning to really master
>> the tool. Of course some guidance helps, but the documentation isn't
>> very good. For instance setting the entry point on architectures with
>> no operating system may bloat the executable, if you don't know what
>> you're doing.
> 
> Name mangling conventions have nothing to do with bloat, neither do
> object file formats, byte order, etc. What a linker does *is*
> conceptually trivial - it merely concatentates the binary data in the
> object files together and writes it out.

To me it feels like a modern linker is more a simple compiler than a 
'cat' utility. 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. 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).

> 
> 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.

> 
> If you want to know where the size in your exe file is coming from, the
> map file will tell you - broken down by each name and its associated
> size.

Right.

> 
> Maybe the problem is the man page for ld, which has a truly bewildering
> quantity of obtuse options, confusing people about what a linker
> actually does.

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.



More information about the Digitalmars-d mailing list