So, will it enable making a user friendly frontend to GDB for Linux?
Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
31–40 of 42 posts
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#32I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
I've seen this best debugger thing come up a few times before. I'm currently working with windows on a project right now and I'm finding the VS debugger more limited than GDB. With GDB I can create scripts which analyse and print complex memory layouts very quickly and efficiently. With valgrind, I can find memory leaks and other unwanted behaviors. With gcc's dump-tree family of options, I can see how my code is tur…
I use Linux (and GDB) at work and home for C++ stuff, and unfortunately, GDB (even with pretty printers configured correctly) often doesn't work correctly for things like templated params, templated classes.
Sometimes GDB won't show locals properly, and just shows even though it's an -O0 -g build.
Also, GDB can get really slow with large binaries with loads of symbols when you have pretty printers installed, even to step through stuff. VS's debugger copes with the same code, and displays everything.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#33I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
I have debugged a C# application in VS and a Java application in IntelliJ and in Eclipse. I did not see any debugging features in VS that can claim its superiority over the others. May be I have not used all the features that were available. Are there any features in VS debugger that are better or non-existent in Java IDEs?
I haven't used IntelliJ, but "Set Next Statement" was what I missed most using Eclipse.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#34Earlier quoted context omitted.
> VS has the best debugger Not to nitpick or disregard the rest of your comment (VS has a really good debugger), but "best" always required qualifying. Best in what cases? Best in what way? There are times when the "best" debugger available without a doubt is WinDbg, with it being archaic, oldfashioned, command-line based, completely un-automated and all that fully accounted for. Why? Because I can copy the 500KB exe…
VS can debug processes on remote machines with only a small helper process running on that machine, and while you shouldn't deploy PDBs onto your production servers, there's no reason not to generate them for your release builds.
>while you shouldn't deploy PDBs onto your production servers
Why? I do it all the time and getting line numbers in the exception logging seems like a nice bonus.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#35I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
I have debugged a C# application in VS and a Java application in IntelliJ and in Eclipse. I did not see any debugging features in VS that can claim its superiority over the others. May be I have not used all the features that were available. Are there any features in VS debugger that are better or non-existent in Java IDEs?
Unless you buy JRebel, VS supports a lot more Edit-and-Continue (JVM hot code swap) operations.
I'm also not sure if you can execute Java 8 lambda expressions in the watch window while debugging.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#36I've been using VisualGDB at work to do embeeded programming on a Cortex M4. Hopefully these guys can benefit from this new Microsoft code, as some things like expression eval don't work in VisualGDB.
Doesn't this replace VisualGDB?
VisualGBD would still potentially be useful for setting cross-compilers and in-circuit debuggers. But yeah, I think you could probably recreate the experience by putting the pieces together yourself.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#37Earlier quoted context omitted.
I've seen this best debugger thing come up a few times before. I'm currently working with windows on a project right now and I'm finding the VS debugger more limited than GDB. With GDB I can create scripts which analyse and print complex memory layouts very quickly and efficiently. With valgrind, I can find memory leaks and other unwanted behaviors. With gcc's dump-tree family of options, I can see how my code is tur…
So my question is, what makes VS's debugger the "best debugger", what am I missing? It's not (just) features, it's the interface to those features. The possibility cap may be lower for you, but that doesn't matter to people who just want an approachable interface to step through their code. This is the part where I'm an elitist asshole: There are developers that program by spending all day, every day in the debugger.…
I have to agree here... When I've had to fall into using a debugger pragmatically VS integration is probably the best experience I've had (eclipse, intellij etc don't compare).
That said, having been working a lot with node/iojs modules the past few years, I find that experience even better. I'm pretty sure others who are using scripted languages with a REPL can probably state the same. Running in an environment where you can jump in anywhere, call a particular script and replace variables for testing is a powerful experience.
I don't mean to start a scripted vs. compiled war... they both have their place. Just mentioning because people will reach for a compiler for things that could be much simpler with a scripted environment more often than not.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#38Earlier quoted context omitted.
I have debugged a C# application in VS and a Java application in IntelliJ and in Eclipse. I did not see any debugging features in VS that can claim its superiority over the others. May be I have not used all the features that were available. Are there any features in VS debugger that are better or non-existent in Java IDEs?
I haven't used IntelliJ, but "Set Next Statement" was what I missed most using Eclipse.
IntelliJ doesn't seem to have it either, which is a pity. It happens quite often that I accidentally step over a line that does something I wanted to step into. In VS, if I know that that line doesn't have any bad side effects when executed twice, I can just pull the instruction pointer (the yellow arrow) back up and step into the line this time.
Another thing I frequently miss in other debuggers is being able to place break-points on statements, not just lines, e.g. the individual parts in a for loop header.
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#39So, will it enable making a user friendly frontend to GDB for Linux?
"... it should be relatively easy to adapt the code to work correctly with your other GDB and LLDB targets from Visual Studio". Right now it targets the version of GDB that ships with Android NDK 17+ and the version of LLDB that Microsoft ships to support iOS debugging.
Also there is a link that shows how to remote debug a Linux process from Visual Studio - http://blogs.msdn.com/b/vcblog/archive/2015/04/29/debug-c-co...
Re: Open Sourcing Visual Studio’s GDB/LLDB Debug Engine
#40Earlier quoted context omitted.
So my question is, what makes VS's debugger the "best debugger", what am I missing? It's not (just) features, it's the interface to those features. The possibility cap may be lower for you, but that doesn't matter to people who just want an approachable interface to step through their code. This is the part where I'm an elitist asshole: There are developers that program by spending all day, every day in the debugger.…
I have to agree here... When I've had to fall into using a debugger pragmatically VS integration is probably the best experience I've had (eclipse, intellij etc don't compare). That said, having been working a lot with node/iojs modules the past few years, I find that experience even better. I'm pretty sure others who are using scripted languages with a REPL can probably state the same. Running in an environment wher…
> having been working a lot with node/iojs modules the past few years, I find that experience even better. I'm pretty sure others who are using scripted languages with a REPL can probably state the same
In Ruby-land, the pry gem called on a binding (binding.pry) is a godsend.