6 ms·

Can you tell me some of the things that VS does much better? I've only ever used GDB, and I am kind of lost when trying to debug a binary on windows

jussij 9y ago
> I am kind of lost when trying to debug a binary on windows When I want to debug a program using the Visual Studio IDE I do the following: 1. Start the IDE and open the solution file. 2. Make sure the Debug Build option is selected. 3. Open a given file in the solution that I want to debug. 4. Select a line in that file and use the Debug, Toggle Breakpoint menu to set a breakpoint. 5. Run the debugger using the Debug, Start Debugging menu and wait for the breakpoint to be hit. 6. When that break point is hit just use the debugger to examine the state of the program.
- jjoonathan 9y ago
  > a binary I'm not sure that there's a VS project and source code available for the binaries in question.
  - to3m 9y ago
    Well if there isn't, you can start the EXE and do Debug|Attach from VS. Or (I think?), you can go to File|Open Solution, open the EXE directly, and let VS create a temporary solution for you that will let you run the EXE as a debuggee by pressing F5. If you're debugging an EXE without source because you're writing a plugin or addon for it as a DLL, and you want todebug that DLL, you can specify the EXE in question as the EXE to run when you start debugging as part of the properties for the project for the DL in question. Visual Studio will spot when your DLL loads, load the debug info for it, and activate any breakpoints and so on. Works well. (If your addon runs as a child process, you need the Child Process Debugging tool. Transformative. Get it here: https://marketplace.visualstudio.com/items?itemName=GreggMiskelly.MicrosoftChildProcessDebuggingPowerTool https://marketplace.visualstudio.com/items?itemName=GreggMis...) When you don't have source code, VS is not the best environment ever - it's oriented very much towards worknig with C/C++/etc., and there's a few options you have to play with to get it to show you disassembly and so on. But it's adequate. (One thing I like about it very much is that the step commands are the same whether you're stepping through source code or whether you're stepping in the disassembly window. I'll put up with quite a lot in exchange for that.)
  - goldfire 9y ago
    In Visual Studio 2017 you can open an executable directly and begin debugging it without having either of those things.
- corndoge 9y ago
  While a simple series of steps it's still pretty complex compares to the equivalent in gdb: $ gdb ./binary (gdb) break file.c:line (gdb) run I think this is merely a disguised version of the "CLIs are too hard" argument...
  - criddell 9y ago
    Visual Studio has a command window that you can use if you want to type commands rather than use the GUI. Plus, the person you replied to was being very descriptive. Just as you start gdb and pass the binary name as a parameter, you can do the same in Windows by double clicking on the solution file.
  - akovaski 9y ago
    However, it is a lot more intuitive compared to gdb: Click the green arrow. Click the line you want to set a breakpoint on. See where you stopped in the same editor that you wrote the code in. Hover your mouse over variables to see their values, visually explore class and array variables. Dig down into functions that are about to be called, before you actually call them.
  - xixor2 9y ago
    > While a simple series of steps it's still pretty complex compares to the equivalent in gdb: Oh come on. If you're developing with visual studio, you've already got it open and have been compiling with it. Debugging in VS is literally click the mouse where you want to stop, F5, full call stack/local variables there in front of you. Given the list above, if you reproduce a similar list for gdb it is also pretty tedious: run a terminal emulator, spawn a new shell, cd to the directory you want to work in, compile the program with gcc with the appropriate flags, run gdb with the appropriate arguments.
  - ksk 9y ago
    Calling it "CLIs are hard" is trivializing it but anyway, it depends on what your common case is. For C/C++, CLIs slow me down tremendously. In an IDE, You don't need to type a single command to view program state (automatic + local + thread storage), call stacks, memory usage, CPU Usage, Heap activity, unpacked C++ containers, GPU state, etc. But this is not even that impressive TBH. FME Windows in general is better at debug symbol management than Linux especially when it comes to shipped binaries. The post[0] sums it up nicely: "I can take a crash dump file from a customer running an arbitrary version of our games, running on an arbitrary version of Windows, load it into the debugger and have all of the symbols automatically show up. I don’t need to know or care what version of the game or what service pack of Windows the customer was running, and I don’t need to think about package names or new repositories. The symbols and binaries Just. Show. Up." [0]https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/ https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...
- jcelerier 9y ago
  So... just like every IDE that integrates GDB then ?
  - alkonaut 9y ago
    Exactly. gdb is just like gcc. I can see the point of having a command line version of a compiler for toying and for automation/build scripts etc, but I rarely see the need to type out compiler commands. Same with a debugger.
- cma 9y ago
  Now try complex logic, only break here if this this and that happened just before. GDB can be much better for that. Where VS shines for me is inspecting the state of datastructures. As long as you don't need to do any complex search on them, or programmatically walk a graph of them.
alkonaut 9y ago
Debugging a binary that you don't have source to, and that you don't intend to modify the reduces the benefit of the full IDE (where your syntax view in debugging is the same as your editor). Still, you get all the niceties of the IDE. You break on a line, step further on some lines. Notice the bug happen after y = foo() + bar(). So you wonder "where are those?" and you F12 with the cursor on the method name to nav to that method once there you set a breakpoint on the first line, and run so you debug that next. Also, if you add in edit-and-continue so you can modify the code and have it automatically recompiled and keep debugging it, that adds value too. I assume that various editor adaptations for vim/emacs etc means that you get almost all the IDE experience with gdb as well (symbol navigation, syntax highlight etc) and at that point there is of course little difference between one IDE and another.

jussij 9y ago

> I am kind of lost when trying to debug a binary on windows When I want to debug a program using the Visual Studio IDE I do the following: 1. Start the IDE and open the solution file. 2. Make sure the Debug Build option is selected. 3. Open a given file in the solution that I want to debug. 4. Select a line in that file and use the Debug, Toggle Breakpoint menu to set a breakpoint. 5. Run the debugger using the Debug, Start Debugging menu and wait for the breakpoint to be hit. 6. When that break point is hit just use the debugger to examine the state of the program.

jjoonathan 9y ago
> a binary I'm not sure that there's a VS project and source code available for the binaries in question.
- to3m 9y ago
  Well if there isn't, you can start the EXE and do Debug|Attach from VS. Or (I think?), you can go to File|Open Solution, open the EXE directly, and let VS create a temporary solution for you that will let you run the EXE as a debuggee by pressing F5. If you're debugging an EXE without source because you're writing a plugin or addon for it as a DLL, and you want todebug that DLL, you can specify the EXE in question as the EXE to run when you start debugging as part of the properties for the project for the DL in question. Visual Studio will spot when your DLL loads, load the debug info for it, and activate any breakpoints and so on. Works well. (If your addon runs as a child process, you need the Child Process Debugging tool. Transformative. Get it here: https://marketplace.visualstudio.com/items?itemName=GreggMiskelly.MicrosoftChildProcessDebuggingPowerTool https://marketplace.visualstudio.com/items?itemName=GreggMis...) When you don't have source code, VS is not the best environment ever - it's oriented very much towards worknig with C/C++/etc., and there's a few options you have to play with to get it to show you disassembly and so on. But it's adequate. (One thing I like about it very much is that the step commands are the same whether you're stepping through source code or whether you're stepping in the disassembly window. I'll put up with quite a lot in exchange for that.)
- goldfire 9y ago
  In Visual Studio 2017 you can open an executable directly and begin debugging it without having either of those things.
corndoge 9y ago
While a simple series of steps it's still pretty complex compares to the equivalent in gdb: $ gdb ./binary (gdb) break file.c:line (gdb) run I think this is merely a disguised version of the "CLIs are too hard" argument...
- criddell 9y ago
  Visual Studio has a command window that you can use if you want to type commands rather than use the GUI. Plus, the person you replied to was being very descriptive. Just as you start gdb and pass the binary name as a parameter, you can do the same in Windows by double clicking on the solution file.
- akovaski 9y ago
  However, it is a lot more intuitive compared to gdb: Click the green arrow. Click the line you want to set a breakpoint on. See where you stopped in the same editor that you wrote the code in. Hover your mouse over variables to see their values, visually explore class and array variables. Dig down into functions that are about to be called, before you actually call them.
- xixor2 9y ago
  > While a simple series of steps it's still pretty complex compares to the equivalent in gdb: Oh come on. If you're developing with visual studio, you've already got it open and have been compiling with it. Debugging in VS is literally click the mouse where you want to stop, F5, full call stack/local variables there in front of you. Given the list above, if you reproduce a similar list for gdb it is also pretty tedious: run a terminal emulator, spawn a new shell, cd to the directory you want to work in, compile the program with gcc with the appropriate flags, run gdb with the appropriate arguments.
- ksk 9y ago
  Calling it "CLIs are hard" is trivializing it but anyway, it depends on what your common case is. For C/C++, CLIs slow me down tremendously. In an IDE, You don't need to type a single command to view program state (automatic + local + thread storage), call stacks, memory usage, CPU Usage, Heap activity, unpacked C++ containers, GPU state, etc. But this is not even that impressive TBH. FME Windows in general is better at debug symbol management than Linux especially when it comes to shipped binaries. The post[0] sums it up nicely: "I can take a crash dump file from a customer running an arbitrary version of our games, running on an arbitrary version of Windows, load it into the debugger and have all of the symbols automatically show up. I don’t need to know or care what version of the game or what service pack of Windows the customer was running, and I don’t need to think about package names or new repositories. The symbols and binaries Just. Show. Up." [0]https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/ https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...
jcelerier 9y ago
So... just like every IDE that integrates GDB then ?
- alkonaut 9y ago
  Exactly. gdb is just like gcc. I can see the point of having a command line version of a compiler for toying and for automation/build scripts etc, but I rarely see the need to type out compiler commands. Same with a debugger.
cma 9y ago
Now try complex logic, only break here if this this and that happened just before. GDB can be much better for that. Where VS shines for me is inspecting the state of datastructures. As long as you don't need to do any complex search on them, or programmatically walk a graph of them.

alkonaut 9y ago

Debugging a binary that you don't have source to, and that you don't intend to modify the reduces the benefit of the full IDE (where your syntax view in debugging is the same as your editor). Still, you get all the niceties of the IDE. You break on a line, step further on some lines. Notice the bug happen after y = foo() + bar(). So you wonder "where are those?" and you F12 with the cursor on the method name to nav to that method once there you set a breakpoint on the first line, and run so you debug that next. Also, if you add in edit-and-continue so you can modify the code and have it automatically recompiled and keep debugging it, that adds value too. I assume that various editor adaptations for vim/emacs etc means that you get almost all the IDE experience with gdb as well (symbol navigation, syntax highlight etc) and at that point there is of course little difference between one IDE and another.