CLion 2016.2 EAP: Remote GDB debug

Hi,

CLion 2016.2 release is just around the corner, and today we have a EAP build (162.1236.1) for you with a long-awaited feature: Remote GDB debug!

To try it download the build from our confluence page, or get a patch-update right in the IDE in case you are using previous EAP build.

Remote GDB debug

This build brings you one of the most voted feature – remote debug. To be precise, CLion now supports remote debug with GDB/gdbserver. That means that having executable running on one host under gdbserver, you can connect to it with the GDB from CLion from another host and inspect the code using all the benefits of CLion’s debugger UI: set breakpoints from the IDE, view variable values, evaluate expressions and more.

Supported platforms

Since GDB/gdbserver is a universal tool, many combinations are possible, from which most popular are debugging on various Linux targets from Linux/macOS hosts. On Windows remote debug is supported from version 2016.3.

Configuration settings

To connect remotely with GDB to the target host, create GDB Remote Debug configuration (go to Run | Edit Configurations and create it from the template) and provide settings for the remote connection, like GDB to use, medium to carry the debugging packets (serial line, or an IP network using TCP or UDP), debug symbols, sysroot, path mappings:
remote_gdb_settings

Core functionality

Finally, simply run the executable on a target system under gdbserver (you can use built-in terminal to access the remote host). And start debugging the GDB remote debug configuration in CLion. The execution will stop on a breakpoints set from the IDE. You’ll be able to view variables, evaluate expressions, set values on the fly, check inline variable views in the editor and more:
remote_gdb_terminal

Limitations and known issues

In case you’d like to debug Linux target from macOS host, you have to use GDB version compiled with --target=x86_64-linux-gnu flag. Get the binutils-gdb sources from the Git repository, switch branch to gdb-7.11.1-release and build like this:

Then select this debugger in the remote GDB configuration.

Be aware, that in case you set this debugger to be used globally in the IDE (in Build, Execution, Deployment | Toolchains settings) local debug on macOS won’t work, so we don’t recommend you doing so.

Besides note, that in case you have sources with symlinks on your host, to make remote debug work open project in CLion using the canonical paths (CPP-7052). Another problem could happen from time to time if you have another target configured in the ‘Before Run’ section of the configuration (CPP-7171).

Please, check the new functionality in case you are interested in remote debug, and provide the feedback to us in the comment section below or in our tracker. Note, that we already have some plans about UI improvements: CPP-7011, CPP-7050.

Environment variables in CMake

Our users asked us to define a way to automatically detect that CLion is used to run the CMake command on the project. After some discussion we’ve decided to introduce special environment variable (CLION_IDE) and implement environment variables completion in CMake to make it easier for you to find it:
clion_ide_cmake
This way now you can detect CLion usage and if so, set special variables/paths or execute some additional scripts of your choice, or just add some extra logging to your CMake.

That’s it! Full list of release notes are available by the link.

Your CLion Team
JetBrains
The Drive to Develop

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

100 Responses to CLion 2016.2 EAP: Remote GDB debug

  1. nigthsuns says:

    good job.

  2. Sidney Just says:

    Yes! This is a huge step for CLion, thank you all so much for the hard work

  3. David Zemon says:

    Well done all! I’m very excited to try this at work tomorrow. Congratulations on getting remote debug in there!

    • Anastasia Kazakova says:

      Thanks! Feel free to share your impression after checking it.

      • David Zemon says:

        Pretty sad start so far :(

        All I see in the console is:


        Cannot configure GDB defaults: Execution finished
        STL pretty printers are not initialized for /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb

        And more alarming is that the GDB tab in the Debugger tab is empty. Shouldn’t I normally see the standard GDB startup output, like the license info?

        I have GDB set to bundled, target remote args don’t seem to make a difference (I tried “foobar” with no change) and both symbol file and sysroot are empty. No path mappings either.

        • David Zemon says:

          This problem may revolve around library compatibility. I get the same error when running a local debug session:


          Process finished with exit code 0
          Cannot configure GDB defaults: Execution finished
          STL pretty printers are not initialized for /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb

          And again, empty GDB tab. If I try to invoke the bundled GDB executbale from the terminal, I get errors:

          igen006@omhqv12915:~$ /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb
          /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb: /lib64/libc.so.6: version
          GLIBC_2.15′ not found (required by /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb)
          /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb: /lib64/libc.so.6: version GLIBC_2.14' not found (required by /privdir/igen006/software/clion-162.1236.1/bin/gdb/bin/gdb)
          igen006@omhqv12915:~$

          I will open a ticket in YouTrack for this.

        • Olof says:

          I have this problem as well. As a data point, if I run the tests outside the debugger it works.

      • David Zemon says:

        If I use the system default GDB instead of bundled, I get better progress, but still failure. I’m running 64-bit CentOS 6.6 which has GDB 7.2 (I know… CLion warns only 7.8-7.11 is supported).

        My console tab now shows that it is connected:

        STL pretty printers are not initialized for /usr/bin/gdb
        Debugger connected to tcp:omhqv12916:2345

        and the GDB tab shows _something_ at least.

        GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
        Copyright (C) 2010 Free Software Foundation, Inc.
        License GPLv3+: GNU GPL version 3 or later
        This is free software: you are free to change and redistribute it.
        There is NO WARRANTY, to the extent permitted by law. Type "show copying"
        and "show warranty" for details.
        This GDB was configured as "x86_64-redhat-linux-gnu".
        For bug reporting instructions, please see:
        .
        Cannot access memory at address 0x7420656c62616e5d
        Cannot access memory at address 0x7420656c62616e5d
        Cannot access memory at address 0x7420656c62616e5d
        Cannot access memory at address 0x7420656c62616e5d
        Cannot access memory at address 0x7420656c62616e5d
        Created trace state variable $trace_timestamp for target's variable 1.

        • David Zemon says:

          These memory errors turned out to be user error. I was loading the wrong symbols. Once I loaded the correct symbols, debugging worked nicely. Looks like it isn’t loading my ~/.gdbinit file though. And I’m still not sure why the bundled gdb doesn’t work

  4. Brian Topping says:

    git clone -b gdb-7.11.1-release --single-branch git://sourceware.org/git/binutils-gdb.git will help speed things up if your connectivity to sourceware.org is not great.

  5. Brian Topping says:

    For OS X folks: I updated Homebrew for the 7.11.1 version of GDB. PR is at https://github.com/Homebrew/homebrew-core/pull/2785. Feel free to go add “thumbs up” there :)

    • Brian Topping says:

      And it’s applied for some days now. OS X Homebrew users can just do brew install gdb to get the latest.

  6. Roman says:

    Is it worth trying to launch remote debug with OpenOCD GDB server on Intel Quark board? Or it will not work for sure?

    • Anastasia Kazakova says:

      We haven’t tested the case, but no obvious reasons why it shouldn’t work, so you’d better try and share the results with us. Thanks.

      • Roman says:

        No, does not work properly. But remote gdb log shows it has connected and set breakpoints. However it does not stop on any breakpoint and I have no control over remote target.

        Clion says GDB view is “read only”, so I can’t enter any commands to experiment.

        Also it would be nice to have some startup options, like in Eclipse “GDB Hardware debugging” plugin, for example I want to sent a halt command after connection to remote target. Currently I receive an error in Clion:
        “Unexpected response: @”target running\n” in Frames and Variables views.

      • Roman says:

        I don’t think it makes sense for you to investigate in this direction before you implement assembly support in Clion. Obviously, the first thing I want to debug on embedded target is boot code that will do system initialization, configure interrupts, stack etc.

        • Anastasia Kazakova says:

          Could you please describe this case in tracker in details? Looks like we are missing some real cases from our users that can help us make decisions about how remote debug should be supported in CLion. Thanks in advance.

          • Roman says:

            I don’t know why gdb console is not working in Clion with remote debug. I guess you will have to experiment with OpenOCD yourself, I can’t help here with a detailed bugreport.

          • Anastasia Kazakova says:

            Ok, I see, thanks.

  7. R. says:

    I just spent some hours testing clion. Probably it’s quite nice for C++ developers; after all Jetbrains has some experience with IDEs.

    For a C developer, however, it seems to be just useless crap.

    My anger doesn’t stem from clion not yet being perfect. It stems from the fact that Jetbrains made clion bluntly, offensively and brutally C-ignorant and, no matter what they propagandize, C++ only. To make it worse Jetbrains also lied (A cross-platform IDE for C and C++)

    You can’t even create a C project; *every*thing is C++ focussed only.

    Following Jetbrains advice to create a C++ project and to hand-edit(!) it to become a C project in the Cmake file doesn’t work. It merely vomits a ton of errors.

    I take clion to be a scam that misleads customers by promising what it doesn’t care about the least.
    We are used to get crap and PR blabla, based on market studies from the usa. From Jetbrains I expected better and more honest.

    • Anastasia Kazakova says:

      Sorry for making you feel that way, but could you please share what kind of error you’ve got?

      Anyway we do plan to add C-project template: https://youtrack.jetbrains.com/issue/CPP-860. Hopefully, we’ll do soon. Anything else you think is a ‘must-have’ for C developers? Please, share your ideas here. We’ll be glad to know.

    • Sebastian says:

      I agree that C support could be better and the fact one must create a C++ project and then manually rename main.cpp to main.c and edit the CMake file is not very elegant. It would be nice if CLion had an internal concept of the project model being C, C++ (or mixed?) and if the UI would react to that, for example when creating new files it could select .c/.h pairs for C projects and .cpp/.h pairs for C++ projects.

      But the statement that CLion is useless for C is not quite true. I have successfully worked on several open source C projects. There are some minor glitches with syntax highlighting and the parser reports some false errors, but generally it works.

      When you create a new project with CLion, just rename the main.cpp to main.c, then in CMakeLists.txt change the following:

      Replace:
      set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -std=c++11”)

      with
      set(CMAKE_C_FLAGS “${CMAKE_C_FLAGS} -std=c11”)

      and:
      set(SOURCE_FILES main.cpp)

      with:
      set(SOURCE_FILES main.c)

      Of course you also have to replace the content of the main.c with some C proper C code. But if you are a C programmer you should know how to do that.

  8. Sebastian says:

    Anastasia,

    CLion has got CMake variable completion since a few releases, but it seems that not all valid CMake variables are recognized by CLion.

    For example when I use the PkgConfig module and do something like:

    find_package(PkgConfig REQUIRED)
    pkg_check_modules(GTK3 REQUIRED gtk+-3.0)

    Then the pkg_check_modules function exports (among others) the following variables:

    GTK3_INCLUDE_DIRS
    GTK3_LIBRARY_DIRS
    GTK3_LIBRARIES

    See here for a complete list: https://cmake.org/cmake/help/v3.0/module/FindPkgConfig.html

    It would be quite helpful if CLion could recognize these variables, and also if I could inspect the value of theses variables. Do you know if there is an open issue for that already?

  9. Tom Alexander says:

    This was released just in time! I’ve started working on cross-platform development for an embedded ARM target and have gotten cross compilation and cross platform remote debug to work with this early access release. I haven’t ported an real source code over yet though, that will be the real test.

  10. Pingback: The Week in C++ 2016.27: July 3rd-9th | Utah C++  Users Group

  11. Ewout Boks says:

    Hello,

    congratulations on expanding CLion’s capabilities, I like using it very much!
    I am trying to debug remotely an arm cortex-m0 (stm32f0) . For that purp
    ose I have a gdb init file with gdb commands to set up GDB to connect to my hw debugger (JLink) .
    normally I would load the file into gdb with
    arm-none-eabi-gdb -x jlinkstm32f072gdbinit.gdb .

    How do I set up the “-x jlinkstm32f072gdbinit.gdb” in CLion’s remote debugger set-up ?

    Thanks !

  12. andreabertini says:

    If you can do what he does VisualGDB with CLion could not be more complete and powerful.

  13. Jens says:

    Hi,
    I am using a .gdbinit with some custom “monitor” commands needed for my remote target. One of the monitor commands makes gdb output a custom string. When this happens, CLion aborts the debugging session with “Cannot configure GDB defaults: Unexpected response: ….”.

    I have not found a way to make gdb to not output this. Is it possible to somehow make CLion ignore this output and continue?

  14. lan says:

    I hope the debug from windows to linux gdbserver comming soon,the function is very important

  15. Bob says:

    Hello, I try to debug Linux target from macOS host, bug the c++ file not stop on breakpoint.
    What’s the problem

    • Bob says:

      and the console shows:
      Debugger connected to tcp:192.168.60.153:8080
      Debugger disconnected

    • Anastasia Kazakova says:

      Please, check the configuration settings:
      – GDB (should be non-default on macOS to debug Linux target)
      – symbol file (with debug symbols)
      – path mappings between remote and local host

      • Bob says:

        the debugger connected to gdb server on linux, but not stop on the breakpoint I set in Clion, it just run to the end and exit

      • Bob says:

        I compile the c++ source file on linux and copy it to OSX host as symbol file

        • Anastasia Kazakova says:

          You have to provide path mappings (Linux < -> macOS) as well in that case. Otherwise GDB on macOS won’t get correct paths to stop on breakpoints in your code.

  16. Ps says:

    I’m trying to debug a microcontroller but I’m having trouble finding a place to put the needed GDB commands because there are no options for a GDB script for remote debugging. Was it left out intentionally?

    When I try to create a bash script that includes the ‘-x myscript.gdb’ and any other arguments passed to it, debugging doesn’t work. I hope I’m just missing something…

  17. Bob says:

    My clion working path on OSX is /Users/n-188/clion/test, a main.cpp file, mapping path to /home/n-188/clion/test on linux
    Please check my step
    1 : gcc -o main main.cpp
    compile main.cpp on linux
    2: gdbserver :8080 main
    run gdbserver on linux
    3: copy the execute file main to my local mac host
    4: Configuration settings
    config local gdb and target remote args
    config the main file as symbol file
    config path mapping:
    /home/n-188/clion/test /Users/n-188/clion/test
    5: run the gdb debug, the debugger connected to gdb server
    and run to end
    I still don’t know how the remote gdbserver find the breakpoints I set on the main.cpp file on my local clion.
    Thank you very much

  18. Suresh Subramani says:

    How do I remote debug the code running on mac host with CLion running on the same host too, using lldb, since that is what is used for CLion on OS X.

  19. Mikhail Romaneev says:

    Hello!
    To be able to attach to local processes with gdb on Ubuntu 14.04 (and I think on most linux systems with kernel protections) user have to make some changes in Ubuntu config files, specifically in /etc/sysctl.d/10-ptrace.conf . Please add that information to Clion’s user manual. You can read more about that here : http://askubuntu.com/questions/41629/after-upgrade-gdb-wont-attach-to-process .

  20. Jose Clua says:

    Hi,

    Please help. I am trying to remote debug using gdbserver/CLIon without success.

    I am able to debug using terminal with these commands:
    – gdb myprog
    – break myprog.c:4115
    – run –myarg
    – the breakpoint works and I can step in the program

    Now when I try the remote debug using CLion 16.2.2 in Fedora System:
    – in server I run: gdbserver localhost:8080 myprog –myarg
    – I get this: Process data created; pid = 80199 Listening on port 8080
    – In Fedora client with CLion:
    – Settings / Deployment / configure SFTP (upload and download working fine)
    – Download all files from server
    – Edit Configuration
    – Create new GDB Remote Debug:
    – GDB: Default (Bundled)
    – Target: tcp:193.101.144.128:8080
    – Symbol file: {blank}
    – Sysroot: {blank}
    – Path Mapping: server path and local path
    – Place the breakpoint in line 4115
    – Run the debugger
    – on the server terminal I see:
    – Remote debugging from host 172.24.10.2 (this makes me believe I am close)
    – address_string = T:servername:4311
    – In CLion console I see:
    – Debugger connected to tcp:193.101.144.128:8080 (connection works!)

    Although it seems the connection from the GDB server and client is working it seems I – am missing something because the debugger tools (step in, step over, continue, etc.) remain grayed out and the breakpoints are never reached.

    Note: In the bottom of the IDE I see this message: IBus prior to 1.5.11 may cause input problems

    From the first test I know that the breakpoints I am using should work.

    I suspect the way I am using to pass in the program argument (–myarg) in this line: gdbserver localhost:8080 myprog –myarg its not right but I don’t know where else to pass it.

    I am looking forward to be able to debug using this awesome IDE rather than using the terminal. I am close but got stucked here. I really appreciate some help!

    Thank you

  21. Galis says:

    First,thanks clion provide the good job for gdb test. There is a problem when i used gdb to debug my application.When add a watch for the variable ,I got the info “-var-create: Usage: NAME FRAME EXPRESSION.”.Eh,is there any idea for this ?

    • Anastasia Kazakova says:

      Could you please share logs with us when the problem occurs: https://intellij-support.jetbrains.com/hc/en-us/articles/206560589-Debugger-doesn-t-stop-on-a-breakpoint-Debugger-shows-Command-timed-out-What-to-do-
      Feel free to submit them via support. Code sample could be useful as well, if possible.

      • Galis says:

        Oh,I still could not resolve this problem util now.Where can I get the log for clion? Can you tell me your email if possible ?

        • Galis says:

          I have got the log and I found the error at the follow lines.
          2017-01-06 15:14:07,018 [ 21091] INFO – .diagnostic.PerformanceWatcher – Unindexed files update took 14065ms; general responsiveness: ok; EDT responsiveness: 1/14 sluggish, 1/14 very slow
          584 2017-01-06 15:14:07,055 [ 21128] INFO – #com.jetbrains.cidr.lang – Building Module Maps finished in 0 s.
          585 2017-01-06 15:14:07,055 [ 21128] INFO – #com.jetbrains.cidr.lang – Building Module Maps finished in 0 s.
          586 2017-01-06 15:14:07,065 [ 21138] INFO – #com.jetbrains.cidr.lang – Clearing symbols finished in 0 s.
          587 2017-01-06 15:14:07,070 [ 21143] INFO – #com.jetbrains.cidr.lang – Clearing symbols finished in 0 s.
          588 2017-01-06 15:14:07,458 [ 21531] INFO – #com.jetbrains.cidr.lang – Loading symbols finished in 0 s.
          589 2017-01-06 15:14:07,475 [ 21548] INFO – #com.jetbrains.cidr.lang – Building symbols finished in 0 s.
          590 2017-01-06 15:14:07,478 [ 21551] INFO – #com.jetbrains.cidr.lang – Saving symbols finished in 0 s.
          591 2017-01-06 15:14:07,758 [ 21831] INFO – #com.jetbrains.cidr.lang – Loading symbols finished in 0 s.
          592 2017-01-06 15:14:07,767 [ 21840] INFO – #com.jetbrains.cidr.lang – Building symbols finished in 0 s.
          593 2017-01-06 15:14:07,770 [ 21843] INFO – #com.jetbrains.cidr.lang – Saving symbols finished in 0 s.
          594 2017-01-06 15:15:04,919 [ 78992] INFO – term.terminal.ui.TerminalPanel – WARNING: Font Anonymice Powerline is non-monospaced
          595 2017-01-06 15:15:05,007 [ 79080] ERROR – terminal.emulator.JediEmulator – Error processing OSC 1;..os/linux-0.12^G
          596 2017-01-06 15:15:07,193 [ 81266] ERROR – terminal.emulator.JediEmulator – Error processing OSC 1;bochs^G
          597 2017-01-06 15:15:10,058 [ 84131] INFO – brains.cidr.execution.debugger – Debugger started
          598 2017-01-06 15:15:15,587 [ 89660] WARN – brains.cidr.execution.debugger – >-var-create – 0x3356c “((long)(memory_end))”
          599 2017-01-06 15:15:15,588 [ 89661] WARN – brains.cidr.execution.debugger – -var-create – 0x3356c “memory_end”
          601 2017-01-06 15:15:15,595 [ 89668] WARN – brains.cidr.execution.debugger – -var-create – 0x3356c “((struct drive_info)(drive_info))”
          603 2017-01-06 15:15:15,603 [ 89676] WARN – brains.cidr.execution.debugger – -var-create – 0x3356c “drive_info”
          605 2017-01-06 15:15:15,605 [ 89678] WARN – brains.cidr.execution.debugger – -var-create – 0x3356c “((long)(memory_end))”
          607 2017-01-06 15:15:15,643 [ 89716] WARN – brains.cidr.execution.debugger – -var-create – 0x3356c “memory_end”
          609 2017-01-06 15:15:15,646 [ 89719] WARN – brains.cidr.execution.debugger – <^error,msg="-var-create: Usage: NAME FRAME EXPRESSION."
          610 2017-01-06 15:15:45,646 [ 119719] ERROR – terminal.emulator.JediEmulator – Error processing OSC 1;..os/linux-0.12^G
          611 2017-01-06 15:15:50,459 [ 124532] ERROR – brains.cidr.execution.debugger – Remote connection closed

  22. Andre PArodi says:

    This looks good.
    I am trying to debug using arm-linux-androideabi-gdb in ndk. I have a couple of issues.
    – I am selecting my .so file but it doesn’t seem to be loading the symbols. in cmd line gdb i was loading them using set solib-search-path. Would it not be better to support that?
    – when it connect it automatically does a continue. It would be nice to be able to select this. I typically like to hit continue myself.
    – I instinctively feel like I would like to run gdb commands directly in an interactive shell. maybe if the above problem is fixed I wouldn’t feel the urge to.

  23. Jerome says:

    Hi,

    Is there any chance that remote debug using lldb (instead of gdb) will be supported at some point in the future (in this particular case: host = MacOS, target = arm-linux (RPi))?

    Or am I missing something, and is this already possible in some way?

  24. Viacheslav Slavinsky says:

    I’m trying to setup a debug target with JLink. My GDB Remote Debug is set up like so:

    GDB: /opt/arm/bin/arm-none-eabi-gdb
    ‘target remote’ args: 127.0.0.1:2331

    My ~/.gdbinit (it’s not fantastically convenient to have it in ~ instead of project dir btw):
    target remote 127.0.0.1:2331
    monitor reset
    load
    si

    This works perfectly from the the command line. Actually it even works with CLion once I have executed the commands from .gdbinit by hand. But I cannot make it just work when launching the debug configuration. When I launch it, in the Console I see:

    Cannot configure GDB defaults: Cannot change this setting while the inferior is running.
    Debugger connected to 127.0.0.1:2331

    In GDB window I see things like:
    Type “apropos word” to search for commands related to “word”.
    /Users/svo/.gdbinit:3: Error in sourced command file:
    “monitor” command not supported by this target.

    Oh yes it is perfectly supported. If I press pause and enter them by hand, they work. This suggests that CLion runs gdb in some weird way. It does not really help if i try and change .gdbinit. What am I doing wrong? This is extremely frustrating.

  25. Roi says:

    Hi,
    As I didn’t understand it from the text
    * Is it possible to remote debug a linux machine from a windows host (GDB/gdbserver)?
    * Is it possible to specify on the windows host the symbol/source files?

  26. Preethi Srinivasan says:

    I am having trouble using GDB remote debug.
    I have a Linux project which I am trying to develop and build in a Windows PC. I have a remote Linux PC to which I am trying to remotely attach my clion for debugging purposes..

    The error that i am getting in Clion Console is :
    Remote register badly formatted: T0506:0000000000000000;07:305f8f1aff7f0000;10:00fbee192e7f0000;thread:p3563.3563;core:a;
    here: 00000000;07:305f8f1aff7f0000;10:00fbee192e7f0000;thread:p3563.3563;core:a;
    Debugger disconnected

    The message shown in gdb-remote server is :
    Remote debugging from host 10.49.236.45
    readchar: Got EOF
    Remote side has terminated connection. GDBserver will reopen the connection.

  27. Jan says:

    Do I always have to manually start the remote target under gdbserver? Is there something like the following workflow supported? If I Debug the current configuration all of the following steps will be automatically executed:
    1. Build outdated projects
    2. Deploy updated outputs to remote target
    3. Start remote debugging
    It seems like step 2 and 3 must be done manually.

    • Anastasia Kazakova says:

      Currently yes. Remote deploy and remote start is not yet supported. You can however open a built-in terminal and execute commands there.

Leave a Reply

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