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
