|
(Alt+8 gets you an assembly language view in VS. Right click to get the context menu, then select "show source". Similarly, press Alt+5 for a registers window, and right click to select register set(s). (This particular bit of UI isn't exactly amazing, but it does basically work.) Or, for getting an assembly language listing from a build, go to the project properties and select listing file format "Assembly, machine code and source". The format is quite readable.) Things I quite like about it: - no grammar to the command set, just keypresses, and no need to press Return. gdb drives me nuts with its command line... feels like trying to count while somebody shouts random numbers in my ear. I'd probably get on better with a command-line driven version of Photoshop than I do with command-line controlled debuggers - passable support for mixed assembly language/source code debugging (same step commands in all cases) - dockable UI that's satisfactorily configurable and updates as you work, so you can see a lot of stuff at once. I find the gdb text-based UI like trying to look through a telescope the wrong way, and it's even worse if you go for the line-by-line TTY mode - it displays code using the normal VS editor, so you can use the code browsing functionality to look around the code as you work There's plenty of scope for improvement, so while it does a reasonable job, I'm maybe not sure about "best". But... I don't appear to be unique in preferring it to gdb. So if we're going for some kind of democratic vote, then maybe an argument could be made ;) But overall, the main thing I like about the VS debugger is that it's integrated quite well into the VS workflow. When you run your project in VS, you run it under the debugger. You have other options, it's true - but running under the debugger is the most obvious one, so that's what you do. There are times where you need rather complicated stuff doing, and VS is sadly lacking in that regard. But most of the time, when your code fucks up, the VS debugger provides enough to let you figure the problem out, and your code is already running under it, so there you go. (I never found a way to get gdb working quite so well - it starts out with your process stopped, for example, so you have to type "run" to get it going. And I never figured out any way to stop your process without being dumped back to the gdb prompt, like Shift+F5 in Visual Studio. If I actually liked working in gdb, I'd probably just get over this, and/or put the time in to figure out how to fix it. But... I don't.) |