CLion 2019.2 EAP: GDB Server for Embedded Debugging


A new CLion 2019.2 EAP build (192.4787.12) is now available. Download the full build from our site, install it via the Toolbox App, or use a snap package if you are using Ubuntu. A patch-update for those using the previous EAP build will be available shortly.


On-Chip debug with GDB Server

As we announced previously, Embedded Development support is one of our main areas of focus right now. We already had some results to show you in v2019.1, with OpenOCD support and integration with STM32CubeMX, along with major improvements in the debugger like the Memory View.

We are now working on further improvements for general embedded debugging and a peripheral view. In this EAP build, we’ve implemented and polished a Run/Debug configuration for On-Chip debug with GDB Server. This covers such cases as:

  • Using OpenOCD as a standalone GDB Server
  • Using ST GDB Servers (you can get an OS version of the tools on GitHub)
  • Using Segger J-Link GDB Server
  • Using QEMU as a GDB Server
  • Any other specific GDB Server

To get into debugging with GDB Server on your MCU, follow the simple steps:

  1. Get a GDB Server installed on your machine.
  2. Create an Embedded GDB Server Run/Debug configuration in CLion, and provide an executable path, arguments to run the server, and other appropriate settings:
  3. Debug from CLion using this new Embedded GDB Server configuration:
    on-chip debug

Other improvements

Other notable changes include:

  • CMake 3.14.5 is now bundled.
  • For remote projects: changes introduced to the project externally (from outside the IDE) are now automatically synchronized to the remote host.
  • The Member function can be static inspection was updated to avoid false positives in macros, for example when a Boost test macro is used (CPP-16229).
  • The quick-fix that simplifies an expression was updated to behave correctly on ternary operator (CPP-16372).

The full release notes are available here.


Your CLion Team
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , . Bookmark the permalink.

22 Responses to CLion 2019.2 EAP: GDB Server for Embedded Debugging

  1. IvanG says:

    I just updated to latest eap hopping Shell Script plugin is included as it is mentioned in full release notes, but seems not available yet for CLion?

  2. Jonathan Zigler says:

    Hoping for the day that Clion more natively supports embedded linux firmware deveopment, but enjoying the new features for embedded developers. A little less than a year ago I was having to do all this by hand with separate tools. Native support really helps. Keep up the good work!!

  3. guillaume says:

    Is there any progress on debugging when using msvc tool chain ?

    Thanks in advance for any info you might share,

    • Anastasia Kazakova says:

      It’s still under development. Since the debugger there is implemented from scratch, it’s a huge bunch of work to be done. We do our best to make it happen in 2019.2, but I can’t promise anything at this stage.

  4. Roman says:

    I see Ivan had moved from QtCreator bugtracker to Clion bugtracker. Hopefully this will accelerate performance improvements in Clion. While it will be a bad if Jetbrains kills all competition in Linux and start raising prices.

    • Anastasia Kazakova says:

      There is always a competition in C++ IDE market and it actually helps us improve the tool.
      Ivan indeed is working on Clangd in CLion and hopefully will help the rest of the team improve the parsing/resolving experience.

  5. Radek says:

    I need some advice – which solution (if any) could make my work easier.
    My Setup:
    1. Arm7 embedded board running linux – target.
    2. The application is build on PC with Ubuntu using gnu arm cross-compiler.
    3. CLion can be only run Ubuntu – embedded board does not have resources to run it.
    4. I have remote debug setup in CLion where I have to manually copy executable over scp to embedded board and manually start a cross-compiled gdbserver also on embedded. Then I can connect to it from CLion running on Ubuntu.

    Is there a way for me control the embedded debugging without the manual operations directly from CLion? Does any of the new features would allow me to create a configuration which will eliminate the manual operations? I can not do use Full Remote Mode because the embedded side does not have resources for it.

    • elmot says:

      I believe you may at least simplify your development using Before launch steps in your run configuration. Usually there is nothing or only Build step, but you can add steps for uploading files via sftp, run remote commands etc. If it’s not enough, you may configure ‘External Tools’, i.e. your own scripts or application runs. With all of that you may use either GDB Remote Debug or Embedded GDB run configurations.
      If you have any feedback, bug reports, or feature requests, please file or upvote tickets at our youtrack system

      A little bit more information about remote build steps:

  6. Hubert says:

    With each release the performance of IDE is worse and worse. 2018.4 was kind of ok with a few hiccups but 2019.1.x is terrible. Ubuntu 18.04 on 72 core CPU, 64 GB, Clion memory bumped to 4 GB and I need to wait 20 seconds to paste one line of code into 5000 line source file. The only option is to paste without formatting. Even typing is lagged at some moments.
    By comparison VSC works way smoother with significantly less resources. I am not going to wait for next release with performance “improvements”. I am switching to VSC and will check Clion once a quarter just for curiosity. Performance is one thing but as I know inability to turn off completely code formatting/indexing/whatever spins CPU is really bad. Good luck but for now good bye. PS. Don’t ask me for CPU traces as many people did it so far without results. If you claim it helps please publish some test files with performance numbers of indexing/symbol lookup/ etc.

    • Anastasia Kazakova says:

      We feel sorry you are disappointed, but without actual CPU snapshots and thread dumps not sure we can help you. There are dozens of different environments and setups, and we keep constantly improving and working on performance. There are things that improved. Still many things in work. And still, some are waiting for another ones to be finished. We can’t estimate or directly help with your particular issues, unless you share some additional info with us.

  7. Qian Wang says:

    How to display the SWO messages in the console?

  8. Trevor says:

    Trying to get the new embedded debugger working with SEGGER on OSX.

    > WARNING: Unsupported remote command “arm semihosting enable”
    > com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: Target does not support this command.

    how does one disable this?

    • says:

      Apparently, you have a command “arm semihosting enable” or “monitor arm semihosting enable” somewhere. Segger does not support the command, just remove it.

  9. Robert says:

    Has anyone tried to use the embedded feature with a QNX target? I’m trying for days and didn’t find a solution.

    • says:

      What kind of solution are you looking for?

      • Robert says:

        Sorry, didn’t metioned your reply.

        I’m trying to connect to a remote microcontroller via tcp/ip. on the ┬Ácontroller runs qnx 7.0, the contoller itself is a arm V7. I tried the following configuration:!AmnYAZa3oHIHom-fsvBbza4wBhu5?e=GRQZww

        I get this error:

        ---Type to continue, or q to quit---

        com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: Remote replied unexpectedly to 'vMustReplyEmpty': timeout
        Debugger disconnected

        Process finished with exit code 0
        GDB Server stopped, exit code -1073741510

        • says:

          Ok, I see now.

          I think, it’s a bit easier to use Remote GDB Debug configuration rather than Embedded GDB Server, even though both might be used.

          First of all, your utility (ntoarmv7-gdb) should be set up as a debugger but not as gdb server.
          Gdb server should be run on your target device, exposing tcp endpoint to the network, and the debugger must connect to it.
          That might be done via ssh tunnel also with some performance impact. And you need to upload and start your application under gdb server on your target platform. That might be done with some script, probably using plink utility from putty distribution. And you may run the script automatically before starting the debugger, see Before launch and External toolsfeatures.

Leave a Reply to Robert Cancel reply

Your email address will not be published. Required fields are marked *