5 ms·

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

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?

userbinator 13y ago
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.
- cottonseed 13y ago
  The g++/gdb experience for C++ has always been pretty bad. Anyone know how lldb compares?
  - dmm 13y ago
    In what ways is it bad? It works pretty damn good here.
    - celebril 13y ago
      It's bad because it's not as hip and cool as LLVM's offering.
      - mitchty 13y ago
        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.
    - cottonseed 13y ago
      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
      - emaste 13y ago
        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.
        cottonseed 13y ago
        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.

userbinator 13y ago

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.

cottonseed 13y ago
The g++/gdb experience for C++ has always been pretty bad. Anyone know how lldb compares?
- dmm 13y ago
  In what ways is it bad? It works pretty damn good here.
  - celebril 13y ago
    It's bad because it's not as hip and cool as LLVM's offering.
    - mitchty 13y ago
      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.
  - cottonseed 13y ago
    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
    - emaste 13y ago
      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.
      - cottonseed 13y ago
        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.