D Map Treemap viewer

[Rainer Schuetze]

On 28.10.2011 20:44, Vladimir Panteleev wrote:
> On Fri, 28 Oct 2011 20:15:21 +0300, Rainer Schuetze <r.sagitario at gmx.de>
> wrote:
>
>> The map file generated by optlink is not UTF8, it uses compressed
>> symbols, that can be expanded with demangle.decodeDmdString before
>> demangling.
>
> Yeah, the code does that.
>
>> Please also note that the map file is often corrupt:
>> http://d.puremagic.com/issues/show_bug.cgi?id=6673
>>
>> which could lead to bad computed sizes.
>
> Yeah, I noticed. I think it'll show up as bad symbol names in the worst
> case.
>

Do you use the address after the symbol or the segment address at the 
beginning of the line? The latter can easily be screwed up, see the 
single line from one of my map files:

  0005:0 0005:00194A43 
_D7visuald10completion13CompletionSet16OnCommitCompleteMWZi10__FUNCTION6__initZ 
107 0005:00194A44       __D7visuald7comutil10DComObject13sCountCreatedi 
107FCA44

The address after the symbol seems more unlikely to be wrong, but 
chances are you skip a symbol and get bad names.

Wondering why symbols seem quite large, I checked my definition of 
IID_IUnknown that was reported as using more than 30kB, and that is what 
could be seen in the map file.

What's actually happening is that templates used for CTFE are compiled 
into the object file. The code is in separate COMDAT sections which 
means they could be eliminated by the linker, but the data is written 
into the same section as the IID, but without any labels. In my case 
these were either mixin strings or template string arguments.

So, dmd should separate the data into different sections aswell. Even 
better, it should not generate code and data for imported functions and 
templates that were only used in CTFE.

IIRC there are already bugzilla entries for this, but I could only find 
http://d.puremagic.com/issues/show_bug.cgi?id=4767 ATM.