Level up your GDB flow with CLion

For this GDB tutorial, I invited my good friend Phil Nash to show CLion’s less known GDB command features. Phil is a developer at JetBrains.

CLion is an Integrated Development Environment (IDE) for C and C++. GDB and LLDB fully integrate with CLion. You may not even know that GDB runs under the hood, so I thought that this is an excellent opportunity to explore how you can optimally leverage GDB in CLion.

Over to you Phil.

Integrated debugger

You can even add more toolchains, and switch between them.

CLion offers all the fundamentals, such as setting breakpoints, stepping into or out of code, and inspecting variables. But if you’re a GDB expert, you’ll be pleased to know that you still have full access to the GDB console at any time.

A quick note, LLDB is a drop-in replacement for GDB, and it is easier to integrate on macOS, so I use it throughout the video.

Going beyond the basics

In other cases, CLion exposes the more advanced GDB command features. For example, it can evaluate a complex expression, even if it involves function calls. You can declare your variables, just scoped within your evaluation, and even change the state in the program directly or inside the function call. You can add these complex expressions as watches so that you can reevaluate them on every step.

You can do more with breakpoints too.

Do more with breakpoints

If you right-click a breakpoint, you’ll get more options.

You can disable a breakpoint, which is handy if you don’t want to remove it entirely, but stop it from doing anything for now.

You can get a breakpoint to break conditionally based on the evaluation of a single value or an expression.

You can also set a conditional breakpoint to suspend the execution.

That seems odd. Why would you want a breakpoint if it doesn’t break?

Let’s look into that.

You can get a conditional breakpoint to log things, show a message, stack trace, or use the result of another expression evaluation. This is useful if you want to see how a specific state is changing without stopping the program from running.

You can also get it to fire only once by setting remove once hit, or the other way around, keep the breakpoint disabled until it reaches another breakpoint first.

It’s important to remember that breakpoints don’t have to break or suspend so that you can set one to act as a dependency for another breakpoint later. That is useful if your code executes a lot, but you only want to debug when it traverses a particular code path.

You can do even more.

You can go through the general breakpoint dialogue. You can see all the breakpoints in your project and click through to them. And, if you have plugins for other languages like Javascript or Python, then you can set breakpoints for code in those languages too.

There’s another type of breakpoint that CLion supports, the watchpoint.

Watchpoints set on data rather than code

Attach CLion to a running program

You can easily filter the list just by typing. This filter can come in handy especially when the process list gets long. Once you attached a program, the debugger works just the same way as before.

Remote modes for debugging

Note that this remote mode works for Docker containers and many other embedded toolchains too.

Level up your code writing with CLion

In this GDB tutorial, I showed you just some of the less known GDB features in CLion. But there are many things I didn’t explore. One of them is that CLion can also integrate with UndoDB via a plugin for reverse-debugging capability.

I hope you found something new to try out.

Good luck debugging.

Phil Nash & Greg Law

Originally published at https://undo.io.

LiveRecorder is an enterprise software failure replay platform. We help developers Record, Replay & Resolve bugs & accelerate MTTR. https://undo.io