[dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well

[Jason Green]

Re-responses from Eric van Beurden:

> hmm I still don't get how, in a generic way symbols could overlap
> the only think I could come up with if when static functions get
> automatically inlined by the compiler, but that's rather a different
> story (as I'd suspect the inlined function to be a single memory range
> within a container => and in that case returning the shortest matching
> symbol should be fine is there an existing exe/pdb file available for
> further testings


in testing with one of our projects, i was seeing symbols lookups fail
85-90% of the time with the initial versions of dbghelp.  The PDB
files that were being used were generated along with the release build
of the project (it was a C++ project as well).  On further
investigation i found that the lookups were failing because many
symbol addresses and ranges were overlapping.  This seemed to occur on
even unrelated objects and symbols.  I would suspect it was the result
of the optimizations the compiler performed.

I was able to generate PDBs that exhibited this behaviour with every
test app i built under Visual Studio (v7.1 and 8.0Express); even apps
that were only 25 lines long.  Since it was very repeatable and the
project in question would always be using PDBs generated from
optimized release builds i decided to change the symbol lookup method
to take the range into account and to be able to store a sublist of
all symbols whose addresses fall into the same range (15-25% of the
lookups still failed with just the range addition).



> hmm still not sure it's the correct explanation... the 928k value is not
> that clear (and doesn't explain the impact of the order)
> I'd rather fear something like windbg mmaps the first meg of minidump
> upfront, and expects to get most the relevant information (the 5 listed
> streams, potentially header and data, in that mapping)... memory is
> likely to be used differently by another memory mapping, hence getting
> around the 1meg barrier (that's still needs to be further tested anyway)

Sorry, i don't think i explained it properly last time.  The 928kb
stream limiting change was incorrect and should be ignored now.
It very well could be that windbg only mmaps the first 1MB of the file
in an effort to find the SystemInfoStream information (and some
others).  The issue arose when we were performing a minidump that
included a thread with an invalid ESP and EBP value in its Context
struct.  This resulted in us dumping the whole stack buffer (~1.14MB)
for that thread instead of just the used area.  Windbg refused to open
the minidump after that.  It complained that the SystemInfoStream
could not be found (as it came after the MemoryListStream data in the
file).

The stream reordering was done for a couple of reasons:
- to put the smaller, fixed size, standard streams first in the file
where windbg seemed to want them
- to better match the stream ordering that native dbghelp wrote its
minidump files in.

The stream ordering still isn't identical because native does things
such as coalesce all strings into the same area of the minidump file
(instead of putting each string immediately after the stream they
belong to), and group stream data and non-stream data together.