We need your feedback on the fate of Cordbg.exe
We currently ship a command line debugger in the SDK, Cordbg.exe. It's implemented in unmanaged C++. In v2.0, our debugger test team also started developing their own command line debugger, MDbg, written in C# and harnessing the awesome power of managed code.
We don't want to maintain two command line debuggers. We'd strongly prefer to deprecate Cordbg and just go with MDbg. Thus we can redirect our efforts from Cordbg into the actual ICorDebug interface, which benefits all consumers (including Visual Studio and any third party tools).
Unfortunately, MDbg has a pretty different syntax than Cordbg and so we don't want to totally break people depending on Cordbg.
We're considering the follow plan. If you think this plan will cause you grief, please reply to this post and let us know.
1) Ship MDbg in the SDK. This would also include our managed wrappers for ICorDebug. We believe MDbg is a much better tool than Cordbg and users will really appreciate its extensibility model.
2) Give MDbg a Cordbg-emulation mode. This means that MDbg can run with a Cordbg skin. I think this is a win/win:
a. The CLR wins - we only have to maintain a single command-line debugger (Mdbg), which we already have to maintain for our testing purposes anyways. We can free up all resources spent on Cordbg.
b. All ICorDebug consumers win –. We can focus our resources on the real product. Also, people depending on Cordbg are not totally broken.
3) As part of this, we're thinking of not including the following Cordbg commands in the emulation layer because we consider them to be sufficiently obscure that nobody actually uses them:
a. conn[ect]- Connect to a remote device
b. regd[efault] - Change the JIT debugger
c. newobjnc - Create a new object via function evaluation, no constructor
d. > - Write commands to a file (this doesn’t seem to work as people expect anyways)
e. uw[here], ut[hreads], uc[lear] – These are all the interop-debugging test commands that and Cordbg is not officially an interop-debugger.
f. wt - Track native instruction count and display call tree
g. wr[itememory] - Write memory to target process
4) Cordbg's v2.0 beta introduced several new commands. We'd only include the following in the emulation layer:
a. attachn[ame] -attach to a process by name.
b. int[ercept] - intercept a managed exception (new feature in whidbey)
c. # - comment command (very useful for scripts).
5) Other inspection information (such as getting a function's IL-->Native map, or IL debugging) would be available in MDbg via extensions.
6) Cordbg’s fate on other platforms (like Rotor and Compact Frameworks) is still up in the air. Whatever we do, we’ll keep some command line debugger for them. Maybe those platforms will continue to use the native C++ Cordbg. Maybe we’ll get MDbg running on them (that’s a little harder since Rotor doesn’t support COM-interop)
Let me repeat, we’re just considering this plan and it’s all tentative. No commitments. If this all works, we'd expect the vasst majority of people to not notice any change in cordbg and not realize that they're actually using MDbg in an emulation mode. I’d love your feedback about what you think (just post feedback to this blog article).
Comments
Anonymous
October 05, 2004
wt is a great switch. That's the thing I'd miss.
Even if not used in production debugging, it gives a great demo of what goes on inside a simplae when teaching .NET to a classAnonymous
October 05, 2004
I think you should switch entirely to MDbg. CLR and managed code is a way to go. But please provide MDbg a Cordbg-emulation mode.Anonymous
October 05, 2004
The only uncertainty is the Heisenberg principle. Isn't a native debugger "better" in that it has less influence on the internals of the CLR than a managed debugger?Anonymous
October 06, 2004
I would vote for leaving the original CorDbg in the SDK, but deprecated and unsupported...and WITH source code!...and all accumulated documentation. This would serve to satisfy all interests in the matter...including keeping it in both Rotor and CF (i.e., it could be the same source code package that gets included in those SDKs...)
The proposed MDbg emulation mode list of subcommands (left in and out) looks fine on first glance, but it would be sure nice to have the old CorDbg available (but NOT as a separate download!) ((Why does EVERYTHING seen to end up being a separate everso "special" download? Isn't that what SDKs are for?!?!!))Anonymous
October 06, 2004
Hallvard - both Cordbg + MDbg have the same heisenberg properties because they both use ICorDebug. The onyl difference is their implementation (C++ vs. C#).
Now ICorDebug (managed debugging) has a much higher heisenberg effect than native debugging (and interop debugging's heisenberg is even greater).
Steve - fwiw, Cordbg does ship as a sample, in the SDK, with full source code. (see http://blogs.msdn.com/jmstall/archive/2004/10/05/237954.aspx)Anonymous
October 13, 2004
The comment has been removedAnonymous
October 27, 2004
I vote against removing connect. At this point this is the only way to debug compact applications apart from the VS integration.Anonymous
October 27, 2004
The comment has been removedAnonymous
October 28, 2004
That would be even better than CorDbg.Anonymous
August 10, 2005
The Mdbg (a managed debugging written in pure C#) sample, which includes full source, has now been...Anonymous
August 10, 2005
The Mdbg (a managed debugging written in pure C#) sample, which includes full source, has now been...Anonymous
August 13, 2005
Soma (my boss's boss's boss's boss) recently blogged about how the CLR took a major change to fix Nullable. ...Anonymous
June 14, 2006
PingBack from http://blogs.msdn.com/jmstall/archive/2005/11/08/mdbg_linkfest.aspxAnonymous
November 22, 2006
MDbg is a debugger for managed code written entirely in C# (and IL), which started shipping in the CLRAnonymous
July 09, 2008
PingBack from http://xavier.supervidsdigest.info/fixesforcordbg.html