4 ms·

Hopefully this replaces GDB, and good riddance.

by yan 16y ago

alec 16y ago
GDB 7.1 is a great improvement over previous versions and has a lot of the features LLDB intends to have - better C++ support, better thread debugging, more accurate backtraces, and a Python scripting API - as well as some features that aren't on the LLDB roadmap yet, like tracepoints for debugging time-sensitive code and multi-program debugging. You should check it out if you're unhappy with an older version.
- wendroid 16y ago
  whatever, still shit, take a look at a proper debugger http://doc.cat-v.org/plan_9/4th_edition/papers/acidpaper http://doc.cat-v.org/plan_9/4th_edition/papers/acidpaper
wazoox 16y ago
Hum, I'd rather wait and see first. What about the truckloads of tools built around gdb (ddd, etc)? And why this should be any better, because it comes from Apple?
- lallysingh 16y ago
  Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means. LLVM is a substantial and fantastic project. At the basis, it's a compiler backend in-a-box. Additional projects, like clang and this, are providing a modern compiler platform for us, finally. gcc & friends have made great advances, relative to other compilers, but they all do suck. It's been 12 years and I still can't use C++ in a debugger without jumping through stupidity. It's literally easier to look at a type definition and read the memory out of a hex dump than go through 16 dropdowns of BS subtype definitions.
  - resistor 16y ago
    > Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means. They employ around two dozen LLVM developers, comprising half to two-thirds of the regular committers.
    - lallysingh 16y ago
      Oh wow.
  - ramchip 16y ago
    I've found the Visual Studio debugger to be very nice, actually. It shows STL classes in an intelligible way, and the IDE integration is (as expected) excellent. Unfortunately OSS alternatives are still a lot less intuitive, and VS is stuck to Windows.
    - lallysingh 16y ago
      I was actually talking about the VS debugger. If you get even a little fancy with templates & metaprogramming, the whole thing is just terrible.
- yan 16y ago
  This is my personal opinion, but the tools built around it either use the gdb protocol which I'm sure LLDB will be implemented to speak, or tools that I don't care about (like DDD you mentioned.. it was just a pain to use). I don't really dislike gdb per se, and it worked well enough for the tasks I used it for, but I just have a personal distaste code conventions of gdb, gcc and other huge GNU projects. I tried spelunking around gdb source to get at some OS X-specific features and tried adding simple instrumentation to GIMPLE trees in gcc's implementation, and both experiences left me with a negative opinion of GNU coding conventions and showed both projects' age. Looking at LLVM source and following their mailing lists is anything but, showing clear direction and clean implementation. I'm not a compiler guy by any stretch of the imagination, but LLVM felt very well-architected and modern. Apple sponsored LLVM after I started following it, so while it's true that they are behind it, it has very little to do with my respect for it.

Hopefully this replaces GDB, and good riddance.

by yan 16y ago

Hopefully this replaces GDB, and good riddance.

alec 16y ago

GDB 7.1 is a great improvement over previous versions and has a lot of the features LLDB intends to have - better C++ support, better thread debugging, more accurate backtraces, and a Python scripting API - as well as some features that aren't on the LLDB roadmap yet, like tracepoints for debugging time-sensitive code and multi-program debugging. You should check it out if you're unhappy with an older version.

wendroid 16y ago
whatever, still shit, take a look at a proper debugger http://doc.cat-v.org/plan_9/4th_edition/papers/acidpaper http://doc.cat-v.org/plan_9/4th_edition/papers/acidpaper

wazoox 16y ago

Hum, I'd rather wait and see first. What about the truckloads of tools built around gdb (ddd, etc)? And why this should be any better, because it comes from Apple?

lallysingh 16y ago
Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means. LLVM is a substantial and fantastic project. At the basis, it's a compiler backend in-a-box. Additional projects, like clang and this, are providing a modern compiler platform for us, finally. gcc & friends have made great advances, relative to other compilers, but they all do suck. It's been 12 years and I still can't use C++ in a debugger without jumping through stupidity. It's literally easier to look at a type definition and read the memory out of a hex dump than go through 16 dropdowns of BS subtype definitions.
- resistor 16y ago
  > Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means. They employ around two dozen LLVM developers, comprising half to two-thirds of the regular committers.
  - lallysingh 16y ago
    Oh wow.
- ramchip 16y ago
  I've found the Visual Studio debugger to be very nice, actually. It shows STL classes in an intelligible way, and the IDE integration is (as expected) excellent. Unfortunately OSS alternatives are still a lot less intuitive, and VS is stuck to Windows.
  - lallysingh 16y ago
    I was actually talking about the VS debugger. If you get even a little fancy with templates & metaprogramming, the whole thing is just terrible.
yan 16y ago
This is my personal opinion, but the tools built around it either use the gdb protocol which I'm sure LLDB will be implemented to speak, or tools that I don't care about (like DDD you mentioned.. it was just a pain to use). I don't really dislike gdb per se, and it worked well enough for the tasks I used it for, but I just have a personal distaste code conventions of gdb, gcc and other huge GNU projects. I tried spelunking around gdb source to get at some OS X-specific features and tried adding simple instrumentation to GIMPLE trees in gcc's implementation, and both experiences left me with a negative opinion of GNU coding conventions and showed both projects' age. Looking at LLVM source and following their mailing lists is anything but, showing clear direction and clean implementation. I'm not a compiler guy by any stretch of the imagination, but LLVM felt very well-architected and modern. Apple sponsored LLVM after I started following it, so while it's true that they are behind it, it has very little to do with my respect for it.