Compilation strategy

[Dmitry Olshansky]

12/18/2012 9:15 PM, Walter Bright пишет:
> On 12/18/2012 8:48 AM, Dmitry Olshansky wrote:
>> After dropping debug info I can't yet make heads or tails of what's in
>> the exe
>> yet but it _seems_ to not include all of the unused code. Gotta
>> investigate on a
>> smaller sample.
>
> Generate a linker .map file (-map to dmd). That'll tell you what's in it.
>
It's rather enlightening especially after running ddemangle over it.

Still it tells only half the story - what symbols are there (and a lot 
of them shouldn't have been) - now the most important part to figure out 
is _why_.

Given that almost everything is templates and not instantiated (thus 
thank god is not present). Still both quite some templates and certain 
normal functions made it in without ever being called. I'm sure they are 
not called because I just imported the module. Adding trace prints to 
the functions in question shows nothing on screen.

I tried running linker with -xref and I see that the stuff I don't 
expect to land in .exe looks either like this:

  Symbol           Defined           Referenced
immutable(unicode_tables.SetEntry!(ushort).SetEntry) 
unicode_tables.unicodeCased
                    unicode_tables

(Meaning that it's not referenced anywhere yet present but I guess 
unreferenced global data is not stripped away)

Or (for functions):

dchar uni.toUpper(dchar)
                    uni               uni

const(@trusted dchar function(uint)) uni.Grapheme.opIndex
                    uni               uni

...

Meaning that it's defined & referenced in the same module only (not the 
one with empty main). Yet it's getting pulled in... I'm certain that at 
least toUpper is not called anywhere in the empty module (nor module 
ctors, as I have none).

Can you recommend any steps to see the web of symbols that eventually 
pulls them in? Peeking at dependency chain (not file-grained but symbol 
grained) in any form would have been awesome.

-- 
Dmitry Olshansky