5 ms·

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 thi

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...
- bennofs 9y ago
  The symbol thing sounds useful and is something I cannot comment on, since most often I either debug open source programs that I run myself (so I have the binary with compiled with debug symbols) or there is no source at all for the binary (and so no symbols). But, most of the other things you listed are, IMO, quite easy with GDB: > view program state in my experience, your often only interested in a few variables. then, you just run display var once for each variable and GDB will show the value of var on every break. There is also `info locals` to show a local variables, and I am pretty sure that you can set it up to run on every break with some simple config (there's probably an extension pack that does it) > call stacks almost every enhancement plugin for GDB in python that I know of does this (GEF, voltron, ...) > unpacked C++ containers I am pretty sure GDB pretty-prints C++ containers? This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either.
  - ksk 9y ago
    >This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either. Surely then, the difference between whats possible, and whats easy/default out of the box isn't simply "CLIs are hard" ! :) Anyway it seems like we'd agree on most things, so nothing really left to discuss.

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...

bennofs 9y ago
The symbol thing sounds useful and is something I cannot comment on, since most often I either debug open source programs that I run myself (so I have the binary with compiled with debug symbols) or there is no source at all for the binary (and so no symbols). But, most of the other things you listed are, IMO, quite easy with GDB: > view program state in my experience, your often only interested in a few variables. then, you just run display var once for each variable and GDB will show the value of var on every break. There is also `info locals` to show a local variables, and I am pretty sure that you can set it up to run on every break with some simple config (there's probably an extension pack that does it) > call stacks almost every enhancement plugin for GDB in python that I know of does this (GEF, voltron, ...) > unpacked C++ containers I am pretty sure GDB pretty-prints C++ containers? This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either.
- ksk 9y ago
  >This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either. Surely then, the difference between whats possible, and whats easy/default out of the box isn't simply "CLIs are hard" ! :) Anyway it seems like we'd agree on most things, so nothing really left to discuss.