Hi folks,

I'm in the process of revamping how Cecil handles debug symbols. A few reasons:

* I can't the stand the current approach that forces a symbol
reader/writer implementation to handle two similar cases (one for a
resolved method body, another one for unresolved method bodies).
* PDB handling misses a few information that break some parts of
debugging in VS (type resolution, iterators, dynamic for instance).
* The Roslyn team is working on a portable debugging symbol format:

https://github.com/dotnet/roslyn/tree/portable-pdb

that I will implement as part of Cecil's core directly, with the hope
that this format becomes prevalent.

--

The plan:

* Move all symbols stuff related to an object accessible from the
MethodBody, say MethodBody.Symbol.
* The type of the object will implement an interface that will be the
common denominator of all symbols (pdb, mdb, pdb-portable), say
IMethodSymbol.
* The readers/writers will only have to deal with this interface (one
code path for reading/writing).
* The writers will try to cast to their specific implementation. For
instance, if you're reading then writing a pdb, the pdb writer will
check if the IMethodSymbol is a IPdbMethodSymbol and will be able to
persist pdb specific information back.

As part of this:

* Obsolete Instruction.SequencePoint for
IMethodSymbol.GetSequencePoint(Instruction). In the future that will
save a pointer in the Instruction type!
* Obsolete VariableDefinition.Name for
IMethodSymbol.GetVariableName(VariableDefinition).
* Change the ISymbolReader/ISymbolWriter contract. I'm not aware of
any external implementer of those interfaces anyway.

--

Jb

-- 
-- 
--
mono-cecil
--- 
You received this message because you are subscribed to the Google Groups 
"mono-cecil" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to