CLion 2016.3 EAP: remote GDB debug, UDL rename and code analysis fixes


We hope you had a chance to try our previous EAP build with lots of changes in CMake workflow and improved overload resolution support. Today we are rolling out another EAP build, 163.7342.13. As usual, a patch update will be rolled out shortly for those using the previous EAP (163.6957.27).

Download CLion 2016.3 EAP

The most valuable improvements include:

Remote GDB debug on Windows

In CLion 2016.2 remote GDB debug was implemented for Linux and macOS platforms. With this build it comes to Windows! The following cases are supported:

  • Debugging of Windows targets built with MinGW (or MinGW-w64) from Windows host with MinGW (or MinGW-w64) GDB.
  • Debugging of Windows targets built with Cygwin from Windows host with Cygwin GDB.
  • Debugging of Windows targets built with one toolchain (MinGW/MinGW-w64 or Cygwin) from Windows host with GDB from another one. In that case don’t forget to provide correct path mappings in the Remote GDB Debug configuration’s settings.

Start your application under gdbserver on remote host, connect there in CLion on Windows and use all the features of CLion’s built-in debugger.

Cross-platform debug (i.e. targets on Linux) requires GDB for Linux to be used from CLion on Windows. The easiest way for it is to build it on Linux with cross-compilation settings. Get the binutils-gdb sources on Linux from the Git repository, switch branch to gdb-7.11.1-release and build like this (here the in-source build is used):

Copy the debugger (build-mingw-w64-x86_64/usr/bin/x86_64-linux-gnu-gdb.exe) to your Windows machine and select in the remote GDB configuration in CLion.

Renaming of user-defined literals

First 2016.3 EAP introduced user-defined literals support in CLion. With this EAP you are now able to use Rename refactoring on such literals:

Besides, Find Usages works now for overloaded operators (except for new and delete), like for example in this case:

Fixes in code analysis

We continue our work on cleaning up the false-positive code analysis along with incorrect quick-fixes in CLion. This EAP build includes another set of fixes. The most important one relates to simplify quick-fix, that previously produced incorrect code for overloaded operators (CPP-2100).

Other fixes cover incorrect Reference may be null case (when one-element initializer list is used) and bogus loop variable is not updated inside the loop warnings.

CMake reload optimizations

CMake project reload can be time-consuming, that’s why we’ve worked on the conditions in which the reload happens to be sure it’s not called when not necessary. Now CLion doesn’t reload project on opening, if nothing changed. Changes that do lead to reload are environment changes, CMake project settings changes and dependent files changes.

Full release notes are available by the link.

Download CLion 2016.3 EAP

Your CLion Team

The Drive to Develop

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

23 Responses to CLion 2016.3 EAP: remote GDB debug, UDL rename and code analysis fixes

  1. Stephane says:

    With respect to cross-platform debugging, I use gdb-multiarch for my needs. Can’t Jetbrains bundle the multiarch version of gdb (built with the –enable-targets=all option if I recall) instead of asking the user to cross-build the debugger? Size increase is minimal compared to the >200MB CLion Download.

    • Anastasia Kazakova says:

      We can consider it. Need to check it out.

      • Stephane says:

        I did some more digging and found that the “all” target has been unmaintained for quite a few years. When debugging on Linux host, I usually use the gdb-multiarch package and had a look at the debian source package. It seems Debian maintain their own target list. I have copied below the configuration parameters that seems to work for me (tested on an arm remote target). I haven’t cross-compiled a toolchain for year, so there might be oversigths. libexpat is required by gdb to exchange cpu information (of different architecture) using xml.

        # libexpat
        ./configure –host=x86_64-w64-mingw32 –build=x86_64-linux-gnu –prefix=/usr/x86_64-w64-mingw32/lib –enable-static

        export CFLAGS=”-Wno-error”
        # From Debian GDB-multiarch source package
        ../configure –host=x86_64-w64-mingw32 –enable-targets=aarch64-linux-gnu,alpha-linux-gnu,arm-linux-gnu,arm-linux-gnueabi,arm-linux-gnueabihf,hppa-linux-gnu,i686-linux-gnu,ia64-linux-gnu,m68k-linux-gnu,m68k-rtems,mips-linux-gnu,mipsel-linux-gnu,mips64-linux-gnu,mips64el-linux-gnu,powerpc-linux-gnu,powerpc-linux-gnuspe,powerpc64le-linux-gnu,powerpc64-linux-gnu,s390-linux-gnu,s390x-linux-gnu,sh-linux-gnu,sparc-linux-gnu,sparc64-linux-gnu,x86_64-linux-gnu,m32r-linux-gnu –disable-gdbserver –prefix=$(pwd)/usr –with-expat –enable-64-bit-bfd –disable-sim

        Hope this helps

        – The libexpat configure options might be wrong as I had to manually install the library
        – CFLAGS=”-Wno-error” is required so the build doesn’t stop on warning.
        – This do not include “bare metal” targets which are getting popular these days (at least in my world). I am unsure if this is required for gdb as it probably does not care about the absence of libc and al.

  2. Olof says:

    It seems we are getting closer and closer to be able to run the IDE on windows but compile and debug remotely against a Linux server.

    What are your plans for the remote toolchain currently?

  3. Olof says:

    I like being able to set where the build happens, but I’m not crazy about how this works.

    The cmake-build-debug/release folder risks ending up in my repo. In a team of many people with many projects I worry that someone is going to accidentally add those files to one or more repos.

    I’d suggest for it to either be auto-ignored, or maybe defaulted into the .idea folder since that is auto ignored (I think). Or alternatively it would work for me at least to give a build root that is used by all projects and that is out of source. I think that would be my preferred solution.

    Thanks for the great work so far. The CMake reload speed and performance just in general have been greatly improved. The previous EAP was a breakthrough for cmake and I was happy to see the improvements in this version as well.

    Performance, stability and false positive squigglies are the main complaints I hear around the office here so please keep plugging at it.

  4. Olof says:

    Whole project.

  5. Ernst says:

    Any chance that you publish a guide how to set up, build and debug on WSL (Windows Subsystem for Linux) from CLion started on Windows ?

  6. Roi says:

    I have the need to debug a linux machine from a windows host (GDB/gdbserver), is it possible to specify on the windows host the symbol/source files and how can I control it?

Leave a Reply

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