[LLVMdev] eclipse and gdb

Tilmann Scheller tscheller at apple.com
Wed Jul 17 04:19:56 PDT 2013


On Jul 16, 2013, at 11:10 PM, Reed Kotler <rkotler at mips.com> wrote:
> 
> The source browsing is way better this way.
Definitely! Once I used this for the first time I never wanted to go back to grep for source navigation, it’s so much faster :)

> How are you setting up the debugger?
> 
> For example, if you want to run from clang but debug the back end code generation ?
I just create a new launch configuration specifying the binary/working directory/command line arguments and run it in debug mode. 

> BTW: do you do builds inside of eclipse.
> Seems to be kind of slow.
I actually never did a build with Eclipse, only used it for code navigation and debugging :)

I do builds with Xcode from time to time when I want to debug from within Xcode (when I’m not using LLDB on the command line) because I haven’t figured out yet how to use Xcode to debug a binary which was built outside of Xcode.

The experience is not that great either though, especially incremental building seems to be kind of broken. E.g. before launching the binary in the debugger it will always build the project first to make sure it’s up to date, so in theory if you run your binary twice and didn’t make any changes to the source code after the first run, then in the second run, you should only have an added overhead of determining that nothing has changed.

However, in practice a significant amount of time is spent on just determining that nothing has changed and it also looks like stuff gets rebuilt even though there’s is no need to. I haven’t spent any time to track down what’s actually the problem there but I assume it has to do with the way CMake generates Xcode projects. It’s possible to start debugging without building though so it’s rather easy to workaround :)

Regards,

Tilmann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130717/18a64d6b/attachment.html>


More information about the llvm-dev mailing list