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

Posted on by Anastasia Kazakova

Hi,

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):

sudo apt-get install mingw-w64 make flex bison texinfo
mkdir build-mingw-w64-x86_64
cd build-mingw-w64-x86_64
../configure --host=x86_64-w64-mingw32 --target=x86_64-linux-gnu --disable-gdbserver --prefix=$(pwd)/usr
make
make install
find usr/ -type f -executable -print -exec x86_64-w64-mingw32-strip '{}' ';'

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:
rename_udl

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

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

JetBrains
The Drive to Develop

Comments below can no longer be edited.

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

  1. Stephane says:

    November 3, 2016

    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:

      November 3, 2016

      We can consider it. Need to check it out.

      • Stephane says:

        November 12, 2016

        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

        Notes
        – 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:

    November 3, 2016

    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:

    November 4, 2016

    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.

    • Anastasia Kazakova says:

      November 4, 2016

      Thanks, Olof. Yes, we’ll consider the options. Probably this feature will help in this case when done: https://youtrack.jetbrains.com/issue/CPP-1887

      • Olof says:

        November 9, 2016

        Also, results from the build directory shows up in searches which almost never is what you want.

        • Anastasia Kazakova says:

          November 9, 2016

          Could you please specify which search you were executing and what went wrong? We do plan some fixes in that area, so just want to understand if it’s exactly the case.

          • Olof says:

            November 9, 2016

            I just did a Ctrl-Shift-f and searched for some word. If that word is in the in source cmake-build-debug path it shows up in the search results.

            In my case I got thousands of false positives from .cbp files in the build directory.

            • Anastasia Kazakova says:

              November 9, 2016

              Thanks. And which scope was selected in Find in Path dialog?

  4. Olof says:

    November 9, 2016

    Whole project.

    • Anastasia Kazakova says:

      November 9, 2016

      Could you please share some screenshot with us (what you’ve searched and what you’ve got). Here or in support.

      • Olof says:

        November 9, 2016

        I have to jump through all kinds of hoops to be able to share things like that. I’m hoping you can reproduce it without that.

        One more note. I marked my build directory as excluded. I’m not sure it matters but per your blog post from a year ago it seems like the thing to do.

        https://blog.jetbrains.com/clion/2015/12/mark-dir-as/

        • Anastasia Kazakova says:

          November 9, 2016

          Ok, thanks anyway. We’ll try to catch it.

          • Olof says:

            November 9, 2016

            I did notice that if I mark the build directory as excluded I no longer get search hits from that directory. So that’s a good work-around.

            • Anastasia Kazakova says:

              November 9, 2016

              Ok, looks like we understand the source of the problem. Hope to fix it in the updates. Thanks you very much!
              The workaround should work indeed, since the problem is that CMakeCache and .cbp files nearby are not excluded from the project. So ‘Marking directory As’ does the job.

  5. Ernst says:

    November 17, 2016

    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:

    March 6, 2017

    Hi,
    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?

    • Anastasia Kazakova says:

      March 6, 2017

      Sure, point to it in the Remote GDB configuration settings.

Subscribe

Subscribe for updates