Compiler: Size of generated executable file
retard
re at tard.com.invalid
Sun Jan 10 23:40:42 PST 2010
Sun, 10 Jan 2010 13:05:12 -0800, Walter Bright wrote:
> grauzone wrote:
>> Walter Bright wrote:
>>> What's hard about "function foo is in the executable, and consumes 421
>>> bytes"?
>>
>> If an executable has > 10000 symbols, it's hard to find out what's
>> actually causing overhead. If you have a script, that categorizes
>> symbol types by demangling the symbol names and creates statistics
>> based on this or so, please post.
>
> It's really not that hard to just look at. The map file even sorts it
> for you, by name and by location.
>
>
>
>>> All a linker does is concatenate the bytes of your generated code
>>> together from the various obj files and write it out. There's no magic
>>> going on.
>>
>> If it's so simple, then why does OPTLINK fail so hard? I can only guess
>> how many people are turning away from D just because they have to deal
>> with OPTLINK's inability to deal with COFF. They end up trying to
>> compile libraries with dmc etc., just to get it linked.
>
> 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.
More information about the Digitalmars-d
mailing list