Debugger options
In CLion, you can debug C/C++ executables with LLDB on macOS/Linux and GDB on Windows/Linux (debugging with GDB on macOS is possible only with a custom GDB binary). Also, there is an LLDB-based debugger for the MSVC toolchain on Windows.
Current versions of the bundled debuggers:
GDB v15.2 for Windows (local debug not supported for Windows ARM64)
GDB v15.2 for Linux
LLDB v19.1.3 for macOS and Linux
LLDB v9.0.0 for MSVC toolchain on Windows
You can also use a custom GDB binary, the supported versions are 7.8.x-14.1.
Go to Settings | Build, Execution, Deployment | Toolchains.
In the Debugger field on the right pane, select the debugger for the current toolchain:
note
LLDB is set as the default debugger on macOS. However, if you had imported CLion settings from a jar file created in Windows or Linux, the default debugger will be set to the bundled or custom GDB version, as it was defined in the system of origin.
In the Settings | Build, Execution, Deployment | Debugger | Data Views | C/C++ dialog, you can customize the C/C++ data representation.
![C/C++ debugger data views settings C/C++ debugger data views settings](https://resources.jetbrains.com/help/img/idea/2024.3/cl_debugger_dataviews_cpp.png)
Here you can control the standard library types rendering, module names, function parameter types and function template arguments, and other options. Alternatively, use the context menu in the Debug tool window, in the Frames view and in the Variables view:
![Frames view context options Frames view context options](https://resources.jetbrains.com/help/img/idea/2024.3/cl_debugtw_frames_contextoptions_dataviews.png)
![Variables view context options Variables view context options](https://resources.jetbrains.com/help/img/idea/2024.3/cl_debugtw_variables_contextoptions.png)
When you set the Enable GNU library renderers checkbox, this affects rendering STL containers by GDB when using the gcc compiler. In the case of clang used in pair with GDB, this option works for libstdc++
only (for more information, refer to next chapter).
Currently this option is not applicable to LLDB. Check how LLDB (starting from version 9.0) handles libc++
and libstdcxx
in LLDB STL formatters below.
Lists given below are accurate for LLDB version 9.0.
Type | libcxx | libstdc++ |
---|---|---|
string | ||
array | ||
vector | ||
deque | ||
list | ||
forward list | ||
set | ||
map | ||
multiset | ||
multimap | ||
unordered_set | ||
unordered_map | ||
unordered_multiset | ||
unordered_multimap | ||
stack | ||
queue | ||
priority_queue |
Type | libcxx | libstdc++ |
---|---|---|
string |
| |
array | ||
vector | ||
deque | ||
list | ||
forward list | ||
set | ||
map | ||
multiset | ||
multimap | ||
unordered_set | ||
unordered_map | ||
unordered_multiset | ||
unordered_multimap | ||
stack | ||
queue | ||
priority_queue |
Combination of GDB as the debugging backend and Clang (the CMake default compiler) implies limitations on viewing the content of STL containers on macOS. As a workaround, try the following instructions.
Use the
libstdc++
library instead oflibc++
. To includelibstdc++
in your project, add the following command in CMakeLists.txt:set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libstdc++")
Alternatively, go to Settings | Build, Execution, Deployment | CMake and specify the library in the CMake options field:
-DCMAKE_CXX_FLAGS="-stdlib=libstdc++"
note
libstdc++ provides support of C++ on the level of GCC 4.2.1. For more information, refer to http://libcxx.llvm.org/.
We also recommend you use the dwarf3 debug info format. For this, add the following commands to your CMakeLists.txt:
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -gdwarf-3") set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -gdwarf-3")
If your project requires more configuration options for debugging, you can create a custom initialization file, .gdbinit for GDB or .lldbinit for LLDB, and place it under the project root. This file can be shared through VCS along with other project files.
tip
Note that .gdbinit/.lldbinit files are not tied to the IDE and work similarly when used outside CLion.
Generally, GDB/LLDB loads several initialization files in certain order during startup. First, the debugger looks for an initialization file in the user's home directory, then for a file in the current working directory (your project root).
By default, commands from project-specific init files are not executed for security reasons. To allow that, modify the init file in your home directory as described below.
Set permissions in the ~/.gdbinit file.
With GDB 11.1 and newer, you can use $HOME
When working with WSL, edit the .gdbinit file located in WSL's home directory,
For all projects
set auto-load local-gdbinit on add-auto-load-safe-path /
note
This allows the debugger to read project-specific init files for all projects, which includes using the command line GDB and allowing it to read .gdbinit from the current working directory. Beware that this can lead to potential execution of untrusted commands.
For a particular project
set auto-load local-gdbinit on add-auto-load-safe-path [full path to the project root]/.gdbinit
Set permissions in the home ~/.lldbinit file:
settings set target.load-cwd-lldbinit true
note
This allows the debugger to read project-specific init files for all projects, which includes using the command line LLDB and allowing it to read .lldbinit from the current working directory. Beware that this can lead to potential execution of untrusted commands.
You can control the GDB timeout values by setting the corresponding properties in CLion registry.
Press CtrlShift0A or choose Help | Find Action from the main menu. In the popup that opens, start typing
Registry
, select the corresponding item and press Enter.In the dialog that opens, start typing cidr.debugger.timeout. Click the Value field of the highlighted string and enter the timeout value in milliseconds.
On Windows with GDB versions prior to 8.0, a separate console is used for application input/output. For the newer GDB versions, the output is redirected to CLion console by default. However, you can switch back to opening an external output window.
Press CtrlShift0A or choose Help | Find Action from the main menu. In the popup that opens, start typing
Registry
, select the corresponding item and press Enter.In the dialog that opens, start typing cidr.debugger.gdb.workaround.windows.forceExternalConsole. Click the Value field of the highlighted string and enter the timeout value in milliseconds.
Thanks for your feedback!