
This is yet another extension built on original Datarescue`s PDB plugin,
(c) servil 2006-2008

Main enhancements from original plugin:
* Integrates advantages of Microsoft Debug Information Accessor (DIA). The
  interface provided by DIA offers more complete description of executable
  against DbgHelp(ImagHlp) API. If DIA server is not installed DbgHelp's engine
  is used (use newest version possible to achieve best results).
* Preserved names mangling on public symbols (ida still shows C prototype where
  full ida typeinfo can't be successfully set).
* Replication of complex types (struct, enum) and typedefs from PDB.
* Scoped UDT members handled (inherited members and nested typedefs, structs
  and enums).
* Exact format to static data symbols and static struct members, forced code at
  function start (extern symbols format preserved).
* Full ida typeinfo to static symbols and struct members.
* Names, exact format and full ida typeinfo to function arguments and local
  symbols stored at frame, recursive traversal all nested sub-blocks of function
  (with DIA only). Supported (both top and bottom) ebp- and esp-based frame
  models, support for register variables and params was removed during testing
  (see known problems and anomalies/#3).
* Source lines import to idabase where file accessible (as anterior lines).
* Foreign program databases support for importing data types only. Selective
  filtering of unwanted types is offered before own storage. For this feature
  call the plugin with argument 2 (use IDC command or edit plugins.cfg for that).
* Alots of minor adjustments not worth to mention.
* No UI (lazy) - always apply all features.

For plugin's functionality either DIA component or DbgHelp.dll must be ready
to use (DIA is preferred).
NOTE: In case of problems connecting to DIA server v8.0 or later you'll
probably have to recompile against corresponding DIA SDK or register DIA server
comming with this distribution - i'm not sure if DIA GUID's are
version-independent.

INSTALLATION:
-------------
Simply copy pdb.plw to <IDA>\plugins\ directory
(replace original pdb.plw or rename to whatever, this version emulates
behaviour of original plugin (autoload at startup)

BUILD NOTES:
------------
Source code should be compatible with MSVC >=6.0 and clones. Source may or not
be compliant with other compilers.
Needed to compile:
* all the files of this package extracted ofcourse
* ofcourse IDA SDK for target version being executed on
* PCRE library compiled (ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/)
* STL with iostreams library. I went with STLport from scratch, so not tested
  with stdlib: if standard violated, use STLport too (http://stlport.sourceforge.net/)
* boost library (http://boost.org/) - just for headers
* Microsoft Debugging Tools for Windows (http://www.microsoft.com/ddk/debugging/)
  or just DbgHelp.h header (note: don't use header file of PSDK - too old for
  backward compatibility with PSDK DbgHelp version)
* Microsoft DIA SDK (part of Visual Studio distribution since VS.Net 7)
* Windows Platform SDK (subset from Visual Studio should be sufficient - if not,
  go with PSDK at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/)
* ATL 3.0 or newer (part of VS) - just for headers
The source was tuned on IDA 5.2. It still probably works on older versions but
backward compatibility not checked anymore. For missing files or other
unresolvable portability problems mail to <servil@gmx.net>.

KNOWN PROBLEMS AND ANOMALIES:
-----------------------------
All listed issues encountered with DbgHelp v6.3.0017.0 (DbgBuild.040415-1850)
and MS DIA component v7.10.3077.0, and may or not be handled better with newer
versions.

1. Names length: (not only) C++ template-specialized names can easily trespass
IDA's MAXNAMESIZE limit. To prevent IDA crashes, all long names are truncated
to MAXNAMESIZE-1 before passing to kernel, however truncated names lose
demangling ability.

2. PDB format design probably keeps old types in pdb file, unfortunatelly
multiple definitions are not versioned nor timestamped any way, thus the plugin
may get two or more diferring definitions of same type. This may cause missing
some elements in complex types or typedefs if plugin creates outdated type.
This problem is partially handled on both DbgHelp and DIA interfaces, but no
warranty is provided by the plugin (workaround works correctly only if
definitions are passed in same order as they were created - newest at last), to
ensure old and new types not jumbled, delete existing pdb file and rebuild
when possible.

3. Local register variables (LocationType=LocIsEnregistered) have
indeterminable load (first use) address and duration. Afaik, there's no
satisfactory rule to tell exactly where respective register is used in context
of it's function scope for the 1st time. register variables are denoted in
function's comment instead creating (supposedly) misguiding regvar.
This problem concerns both DbgHelp and DIA interface.

4. Not all types can be stored to IDAbase due to nonstandard characters (C++
template<> instantiations etc.). Missing types will invalidate all IDA typedefs
referring them, I didnot make typeinfo validity check before storing to IDA but
unresolvable typeinfos produce 'invalid' print-out - plugin makes no character
checks or substitutions.

5. Nested enums (and maybe other types) are placed to global namespace without
notification or full name qualification, Unfortunately NESTED value doesnot
trustworthly tell if name belongs to a local scope (I've seen this flag set for
true global enums too on some executables). This problem is partly handled by
no filtering but rather deleting global enum if constant name conflicts occur.
This problem wasnot observed with DIA so far.

6. Static variables defined in local function scope seem be marked as
register-relative locals with offset(address)=0. For assumption zero BP offset
points to saved BP, I have decided rather to treat all 0-offseted local symbols
as local static variables with unknown address at the cost of discarding
eventual SP-related locals. Anyhow I don't have knowledge to retrieve true
address for these symbols atm.
Local static variables should be handled correctly with DIA.

7. UDT members with non-std. name or type are not created, thus their space may
be undefined (gap). This may cause problems where trying to apply owner UDT as
pure type (such UDT's are commented as incomplete) - however the UDT is named
and can be used as pointer or reference.

8. Not always all struct members are retrieved by SymGetTypeInfo(...). I have
noticed the API sometimes raises access violation, I don't know cause but it
may hear on private or non-public class members. such structures and enums are
commented as 'incomplete'. This problem only concerns to DbgHelp API interface.




Updated 02/04/08:
Due to new features (see below) this version may induce IDA more or less trend
to crash at load of highly complex program databases, so although tested quite
alot, get absolutely no guarantee for successfull load.
- more safe, all typeinfo recursion deadlocks (hopefully) definitely resolved.
  stack overflow on types infinite recursion remains the most impending cause
  of crash at load time
- more aggresive types creation, refused structs and enums (mostly due to long
  or non-std. name) created in til instead, til-only types specifics:
    - not accessible from structs/enums list but from ida typeinfo only
    - UDTs always have default module alignment and can only accept members
      in ascending offset order atm. (all these may be handled in future)
    - UDTs (unlike native IDA structs) can define bitfields
    - can have any name (as for character set and length)
    - can contain or refer types of any name (as for character set and length)
  (refused types created as native IDA types with substituted name despite)
- all types stored to til now are accessible from UI (can be used as func
  params etc.) and are listed in local types viewer also (IDA >=5.2)
- more aggresive long names passing (only truncated at places when ida
  crashed), newer IDA versions may be more resistent against too-long names.
  Too long names are second reason to force IDA crash so this change is
  experimental and may increase instability on older versions.
- DbgHelp(ImageHlp) interface still kept in sync but not tested anymore,
  DIA server recommended
- compatibility with older IDA versions (up to 4.8) still retained, but not
  tested anymore
