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

[Eric Pouech]

Jason Green a écrit :
> 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.
>   
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
>   
>> the patch is already big enough not to mix code evolution with stuffing
>> new trace:s all over the place
>>     
>
> Understood.
>
>
>   
[snip]
> 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.
>   
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)
>
>   

A+

-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)