crashanalysercmd/PerfToolsSharedLibraries/Engine/SymbolLib/Internal/Future Plans.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/crashanalysercmd/PerfToolsSharedLibraries/Engine/SymbolLib/Internal/Future Plans.txt Thu Feb 11 15:50:58 2010 +0200
@@ -0,0 +1,58 @@
+Requirements
+============
+
+1) Unified GenericSymbol class - not virtual
+ - represents individual symbol
+ - must support dynamic relocation by way of GenericSymbolCollection
+
+2) Unified GenericSymbolCollection class - not virtual
+ - represents collection of symbols
+ - must have a PC-side underlying source file name (e.g. .symbol, .map)
+ - must have a PC-side underlying binary file (e.g. \epoc32\release\armv5\urel\Sysstart.exe, \epoc32\release\armv5\urel\euser.dll)
+ - must have an address range, which is sorted and easily indexable in order to find corresponding GenericSymbol
+ - must support dynamic relocation
+ - collection and CodeSeg will have 1:1 mapping
+ - must be able to tag a collection as "in use" so that it's contents can be serialized
+ - must be able to mark a collection is permanent, i.e. it does not need or support relocation
+
+
+3) Unified SymbolEngine class - not virtual
+ - represents a set of 'collections'
+ - must be able to discard unused collections
+ - must be able to serialize tagged collections
+ - SymbolEngines can be layered - so that one symbol engine can build upon another
+ - must be able to list all collections. If layered, then that means providing iteration on the underlying child symbol engines.
+ - must be able to load and unload specific collections.
+ - an unloaded collection does not necessarily mean totally discarded. It may just mean that it cannot be used to provide
+ symbol lookups.
+
+4) Separation of symbol sources (map/symbol/sym/zip) from actual symbol & collection content
+
+5) Must be able to easily plug in new symbol sources without impacting other parsers/sources.
+
+6) Once symbol source data is in memory, then must be able to obtain different views on the data without needing to reparse/reload
+ the symbol source.
+
+ For example, in the case of NICD/System CoreDump stack reconstruction, we need to create call stacks for multiple thread
+ simultaneously. Currently we must serialize access to the symbol engine so that only one stack is reconstructed at any given
+ time because we cannot dynamically load and unload multiple relocatable symbol sources simultaneously.
+
+7) "Resolving" a dynamically-loaded symbol source needs to be a common operation for all source types. We must somehow support a number
+ of resolution methods and all sources should be able to provide resolver implementation that allows 'resolution meta-data' to be
+ created for any symbol sources that they have loaded.
+
+
+Use Cases
+=========
+
+a) Need to be able to zip up all the symbol source files.
+
+b) Asked to read a core rom symbol file, two rofs symbols and 3 map files.
+
+c) Parsing NICD/CoreDump style crash data where serveral stacks all require reconstruction.
+
+
+
+
+
+1) Reading a symbol file fully populates a source