Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

It produces a smaller binary, but that doesn't really give us any information on whether it's a better one.

AFAIK Clang and GCC are now roughly neck-and-neck in terms of performance though (at least as of December) - http://www.phoronix.com/scan.php?page=article&item=llvm34_gc...

View on HN

GCC produces a slightly smaller binary when debug information is stripped, but LLVM produces a massively smaller binary (half as big) when debug information is included. If you're building debug, why would you care how big the stripped binary is?

This invites the question of whether GCC is outputting more detailed debugging information than LLVM (which is a good thing), or if it's just being inefficient at it.

The g++/gdb experience for C++ has always been pretty bad. Anyone know how lldb compares?

In what ways is it bad? It works pretty damn good here.

Generally, failing to parse expressions at the level of abstraction of the source code being debugged: I find it fails on user defined operators, can't resolve overloaded functions, etc.

Even being able to reliably evaluate C++ expressions is far from what I want: I want to be able to execute arbitrary C++ statements (including loops), use templated objects that weren't instantiated at compile time, etc. I feel like this might be close to possible using, say, the LLVM JIT, although I haven't seen anything that implies anyone is trying to build it.

edit: for example (stock gcc/gdb on Ubuntu 12.04):

    #include <iostream>
    int main() { std::cout << "foo\n"; }

in gdb, break at main:

    (gdb) p std::cout << "foo\n"
    Cannot resolve function operator<< to any overloaded instance

edit edit: lldb doesn't fare much better (OSX 10.9):

    (lldb) p std::cout << "foo\n"
    error: no member named 'cout' in namespace 'std'
    error: 1 errors parsing expression

LLDB does JIT your expression via Clang, and then either interprets it locally or executes it in the target, and you can execute arbitrary commands - for example:

  (lldb) expr for (int i=1; i<5; i++) { printf("%d\n", i * i); }
  1
  4
  9
  16

It does still fail if the appropriate constructors, templated object instantiations, etc. aren't in the target, as you point out.

Oh, very nice. That's clearly the right architecture.

It still fails on a lot of things for me (including your above example and the std::cout example, although variants work), which I'm guessing (hoping?) is just a lack of maturity. Looking forward to see how it progresses.

It's bad because it's not as hip and cool as LLVM's offering.

No gdb is bad for c++ debugging because it doesn't include parsing support for c++.

At least I'm not aware of being able to type in c/c++ in gdb on the fly like you can with lldb contexts.

So what exactly is "hip and cool" about having your debugger actually use the same parsing engine as the compiler infrastructure? If you have a technical point make it, otherwise stop being the discussion equivalent of acid.

Reply on news.ycombinator.com