4 ms·

It's not clear to me why we'd need a new debugger instead of GDB enhancements. GDB has an extensible, modern C++ codebase with literal decades of hard earned kn

It's not clear to me why we'd need a new debugger instead of GDB enhancements. GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it. How are we better off rewriting it, especially if the rewrite isn't memory safe?

ziddoap 2y ago
Consider this part of the post: >I've been building a debugger on my nights and weeks because it's fun
- dima55 2y ago
  I'm considering the part that says "GDB and LLDB pain me greatly". This project both says "I'm doing this for fun" and "the state of the art is bad, and I'm trying to fix it", so this is a fair question. GDB is great. He says it crashes a lot, and cannot interpret some of his types. Maybe that's his experience, but I haven't had those issues after literally decades of using gdb. Some bug reports would be nice.
  - Agingcoder 2y ago
    Decades for me as well, and we’ve had very different experiences : gdb is very powerful , but the user experience is atrocious and it does crash a lot. To be fair, in a number of cases the type issues I had were not gdb’s fault but bad DWARF produced by the compiler.
  - marssaxman 2y ago
    After literally decades of occasionally dipping into GDB only to quickly remember why I would rather use no debugger at all than that, it's hard to imagine what you could mean by "great". What are you comparing it to?
chc4 2y ago
> GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it. I literally laughed outloud at this. Have you ever actually opened a GDB source file? It is, as a whole, extremely poor quality code. Almost all of it is doing C string manipulation and raw pointer arithmetic; almost none of it uses C++ smart pointers, nevermind the rest of "modern C++"; the vast majority is completely uncommented, and "literal decades of hard earned knowledge" can be better translated as "literal decades of historical baggage, cruft, and hacks". I regularly cause GDB to segfault in normal, mundane operations.
godelski 2y ago
> It's not clear to me why we'd need a new debugger People build things for fun. Stop asking "why" and ask "why not?" No one can really predict what's needed and where we need to go, so let people just explore. Sometimes they won't find things, but sometimes they do. And if they don't, they still gain useful knowledge that pays dividends later on anyways. It's Hacker News, let people hack.
bregma 2y ago
Well, you can start by tearing down all the fences and firing that Chesterton guy's sorry ass. After all, even a 32-bit ARMv7 uses .eh_unwind sections to crawl the stack for a backtrace, right? Then, you can focus on resolving edge cases that can cause papercuts. Make sure the solutions are at the expense of the happy path because that's all been solved long ago so there's no need to pay attention to it.
modeless 2y ago
GDB is awful and a replacement is sorely needed. It's buggy and slow and feature poor and has a terrible UI and a terrible API which makes all the frontends terrible in turn. I haven't looked at its code but I'm betting it's terrible too.
- gregthelaw 2y ago
  I haven't tried UScope yet (I shall), but I don't agree with you about GDB. I don't find it especially buggy unless doing niche things like non-stop debugging -- I guess you may well have a different experience though. I think the UI is much maligned unfairly. It has a few quirks, but ever used git? For the most part it's fairly consistent and well thought through. By terrible API you mean the Python? I admit it can be a bit verbose, but gives me what I find I need. What features do you most miss? My experience is that most people use like 1% of the features, so not sure adding more will make a big difference to most people.
  - feelamee 2y ago
    > What features do you most miss? one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. But gdb can't call C++ functions from python api (excepting weird hacks like evaluating `print c.begin()` and catching it output). Although this is not very useful because most of types we use changes very rarely, that's why writing printers is only matter of time. Another feature is breakpoints which sleep next N seconds. We have breakpoints which can skip next N triggering, but similar with time will be useful to me to debug mouse events in gui apps, etc. Also the most new gdb still have problems with tab-tab completion (and even Ctrl-C don't return control immediately). Also lately I often meet problem cannot insert breakpoint 0. Probably this is a bug, because answers from stackoverflow isn't relevant for me
    - quotemstr 2y ago
      > excepting weird hacks like evaluating `print c.begin()` and catching it output) Why do you consider that a weird hack instead of legitimate programming technique?

ziddoap 2y ago

Consider this part of the post: >I've been building a debugger on my nights and weeks because it's fun

dima55 2y ago
I'm considering the part that says "GDB and LLDB pain me greatly". This project both says "I'm doing this for fun" and "the state of the art is bad, and I'm trying to fix it", so this is a fair question. GDB is great. He says it crashes a lot, and cannot interpret some of his types. Maybe that's his experience, but I haven't had those issues after literally decades of using gdb. Some bug reports would be nice.
- Agingcoder 2y ago
  Decades for me as well, and we’ve had very different experiences : gdb is very powerful , but the user experience is atrocious and it does crash a lot. To be fair, in a number of cases the type issues I had were not gdb’s fault but bad DWARF produced by the compiler.
- marssaxman 2y ago
  After literally decades of occasionally dipping into GDB only to quickly remember why I would rather use no debugger at all than that, it's hard to imagine what you could mean by "great". What are you comparing it to?

chc4 2y ago

> GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it. I literally laughed outloud at this. Have you ever actually opened a GDB source file? It is, as a whole, extremely poor quality code. Almost all of it is doing C string manipulation and raw pointer arithmetic; almost none of it uses C++ smart pointers, nevermind the rest of "modern C++"; the vast majority is completely uncommented, and "literal decades of hard earned knowledge" can be better translated as "literal decades of historical baggage, cruft, and hacks". I regularly cause GDB to segfault in normal, mundane operations.

godelski 2y ago

> It's not clear to me why we'd need a new debugger People build things for fun. Stop asking "why" and ask "why not?" No one can really predict what's needed and where we need to go, so let people just explore. Sometimes they won't find things, but sometimes they do. And if they don't, they still gain useful knowledge that pays dividends later on anyways. It's Hacker News, let people hack.

bregma 2y ago

Well, you can start by tearing down all the fences and firing that Chesterton guy's sorry ass. After all, even a 32-bit ARMv7 uses .eh_unwind sections to crawl the stack for a backtrace, right? Then, you can focus on resolving edge cases that can cause papercuts. Make sure the solutions are at the expense of the happy path because that's all been solved long ago so there's no need to pay attention to it.

modeless 2y ago

GDB is awful and a replacement is sorely needed. It's buggy and slow and feature poor and has a terrible UI and a terrible API which makes all the frontends terrible in turn. I haven't looked at its code but I'm betting it's terrible too.

gregthelaw 2y ago
I haven't tried UScope yet (I shall), but I don't agree with you about GDB. I don't find it especially buggy unless doing niche things like non-stop debugging -- I guess you may well have a different experience though. I think the UI is much maligned unfairly. It has a few quirks, but ever used git? For the most part it's fairly consistent and well thought through. By terrible API you mean the Python? I admit it can be a bit verbose, but gives me what I find I need. What features do you most miss? My experience is that most people use like 1% of the features, so not sure adding more will make a big difference to most people.
- feelamee 2y ago
  > What features do you most miss? one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. But gdb can't call C++ functions from python api (excepting weird hacks like evaluating `print c.begin()` and catching it output). Although this is not very useful because most of types we use changes very rarely, that's why writing printers is only matter of time. Another feature is breakpoints which sleep next N seconds. We have breakpoints which can skip next N triggering, but similar with time will be useful to me to debug mouse events in gui apps, etc. Also the most new gdb still have problems with tab-tab completion (and even Ctrl-C don't return control immediately). Also lately I often meet problem cannot insert breakpoint 0. Probably this is a bug, because answers from stackoverflow isn't relevant for me
  - quotemstr 2y ago
    > excepting weird hacks like evaluating `print c.begin()` and catching it output) Why do you consider that a weird hack instead of legitimate programming technique?