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

[Jason Green]

Eric, below are the responses from Eric van Beurden, who wrote the
patch.  I merely split it up and removed a bunch of traces for
submission to WineHQ.  The problem is that all of our changes were
done initially in just a couple of huge commits during the initial
import of dbghelp instead of nice, incremental changes.  I split
things up based mostly on a file by file basis, but I can further
split this one as well

On Jan 18, 2008 3:14 PM, Eric Pouech <eric.pouech at orange.fr> wrote:

> what's the rationale of optimized pdb ?

An optimized PDB file is generated with an optimized build of an app.
Symbol addresses and ranges can overlap in these files.  The existing
implementation neither takes that into account when sorting the list
nor when looking up symbols.  This results in symbol lookups failing
~85-90% of the time.

> the patch is already big enough not to mix code evolution with stuffing
> new trace:s all over the place

Understood.

Re: 7/10 - Fix file searching to search only listed directories
instead of the whole HD:
> you failed to set DebugFilePath to the desired value
> again the rest of the patch has nothing to do with the first part of the
> patch

Previously, the FindDebugInfoFile() function was using the function's
return value string <DebugFilePath> as the me of the first file to
open.  This was an error since there is no requirement that this
string be initialized to anything.  However, you are correct in
pointing out that the <DebugFilePath> variable did not get set in the
event that the first attempt at finding the file succeeded.  This fix
will be submitted.

Re: 10/10 - Clamp minidump memory blocks to 928KB:
> if that's really the case (and I'm even not sure we want to support this
> backward compatibility), a good fix would be to add several streams each
> up to 928k instead of clamping

After much  more research and testing this turned out to be in error.
The issue was not actually the size of the single stream, it was the
ordering of the streams that windbg did not like.  Windbg expects the
six standard streams in the following order or else it will have
trouble opening some minidumps:
             SystemInfoStream
             MiscInfoStream
             ExceptionStream
             ThreadListStream
             ModuleListStream
             MemoryListStream
The stream table at the start of the file is sorted in numerical order
by stream ID (as the current implementation has), but the actual
stream data must appear in the above order after the file header.  Our
current fix for this is rather hacky and needs to be fixed properly
and cleaned up before resubmitting.  The proper fix would be to change
the order that each stream is created, then to sort the stream table
by stream ID before writing it to file.