5 ms·

I like GDB, and use it a lot, but it always feels like it's teetering on the brink of being a pile of bugs. I manage to crash it semi-regularly, and there are d

I like GDB, and use it a lot, but it always feels like it's teetering on the brink of being a pile of bugs. I manage to crash it semi-regularly, and there are dozens of little quality-of-life peccadilloes that make things annoying before working out a .gdbinit for yourself. It's like using Vim without a .vimrc (: I don't envy the maintainers' jobs, and I just gripe from the sidelines, but starting from scratch it's too bad it's such an intimidating experience, because it really is a great tool. And I say this as someone who has used MSVC's debugger (which I've often seen applauded as the best) for some decades, and I still prefer GDB now that I'm past the significant initial learning curve.

ncmncm 5y ago
To me coming from GDB, MSVC 's debugger seems like nothing but a flashy toy. It cannot do any of the things I need a debugger to do beyond stepping and setting breakpoints.
- pronlover723 5y ago
  for example?
- edgyquant 5y ago
  Can you give some examples? I’ve never used a debugger for more than stepping and setting breakpoints
  - ncmncm 5y ago
    https://news.ycombinator.com/item?id=30523338 https://news.ycombinator.com/item?id=30523338
  - Groxx 5y ago
    I've used Java's debugger to do "live" UI editing on Android for around a decade now. Far in advance of first-party support / live-updating things being popular. Just set a timer to call back to the main thread every 100ms or so. When you get to the point in an application where you want to make changes, put a breakpoint in that callback. When it pauses, pop open the expression editor and start changing the UI. Make some views, adjust some values, etc. When you want to see the results, hit "continue"; it'll release the main thread for about 100ms (more than enough time to re-layout and render), then you'll be back in the debugger for another round of changes. You can hack up a full, polished-looking and often working UI in a couple minutes, and then just print the whole tree to get a snapshot your work. That same strategy works in basically any language with GDB support, in many, many UI frameworks, if the connection is sophisticated enough to call functions.
- rurban 5y ago
  Real Windows programmers use windbg, which is comparable to GDB. Even better built-ins. But the MSVC dbg UI also has its advantages. Still writing lots of .gdbinit scripts though.
- pjmlp 5y ago
  A proof that you never learned to use that toy. How does the adult version of GDB show threads and parallel stacks and shader debugging? Or better yet, how do adults do hot code reload on GDB?
  - ncmncm 5y ago
    GDB will gladly show you all the threads' stacks. Couldn't tell you about shaders. Haven't needed hot code reload.
    - pjmlp 5y ago
      In a primitive text view like 1970's, letting the use draw on paper the relationship between them, or which tasks are mapped into which thread. So a more powerful debugger that offers stuff beyond what you are aware of in computing, while GDB hasn't be able to do so in 40 years, is a toy.

ncmncm 5y ago

To me coming from GDB, MSVC 's debugger seems like nothing but a flashy toy. It cannot do any of the things I need a debugger to do beyond stepping and setting breakpoints.

pronlover723 5y ago
for example?
edgyquant 5y ago
Can you give some examples? I’ve never used a debugger for more than stepping and setting breakpoints
- ncmncm 5y ago
  https://news.ycombinator.com/item?id=30523338 https://news.ycombinator.com/item?id=30523338
- Groxx 5y ago
  I've used Java's debugger to do "live" UI editing on Android for around a decade now. Far in advance of first-party support / live-updating things being popular. Just set a timer to call back to the main thread every 100ms or so. When you get to the point in an application where you want to make changes, put a breakpoint in that callback. When it pauses, pop open the expression editor and start changing the UI. Make some views, adjust some values, etc. When you want to see the results, hit "continue"; it'll release the main thread for about 100ms (more than enough time to re-layout and render), then you'll be back in the debugger for another round of changes. You can hack up a full, polished-looking and often working UI in a couple minutes, and then just print the whole tree to get a snapshot your work. That same strategy works in basically any language with GDB support, in many, many UI frameworks, if the connection is sophisticated enough to call functions.
rurban 5y ago
Real Windows programmers use windbg, which is comparable to GDB. Even better built-ins. But the MSVC dbg UI also has its advantages. Still writing lots of .gdbinit scripts though.
pjmlp 5y ago
A proof that you never learned to use that toy. How does the adult version of GDB show threads and parallel stacks and shader debugging? Or better yet, how do adults do hot code reload on GDB?
- ncmncm 5y ago
  GDB will gladly show you all the threads' stacks. Couldn't tell you about shaders. Haven't needed hot code reload.
  - pjmlp 5y ago
    In a primitive text view like 1970's, letting the use draw on paper the relationship between them, or which tasks are mapped into which thread. So a more powerful debugger that offers stuff beyond what you are aware of in computing, while GDB hasn't be able to do so in 40 years, is a toy.