5

The Questions

I have a few questions surrounding usage of Intel Pin with C++14 or other C++ verions.

  • There are rarely any problems compiling code from older C++ with newer versions, but since Intel Pin is manipulates instruction level, is there any undesirable side effects that might come if I compile it with C++11 or C++14?
  • If it's ok to compile with C++11 or C++14, how do I make a rule to enable a newer version of C++ for my tool only?
  • How do I set GCC/G++ default C++ version to latest, if possible, and what should I keep in mind when doing so?

Situation

I'm building a dynamic call graph pin tool. To make it understandable, I'm computing the depth of the call stack. For safety, I decided to wrap the excerpt of code that increments or decrements the depth with a std::mutex. This has gotten me to the problem that std::mutex is available only since C++11, which is not Intel Pin default in my machine.

$ g++ -v
[...]
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)

Compile command:

$ make obj-intel64/callgraph.so
[...]
error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support
[...]

EDIT

I managed to make a build rule that defines version to C++11, but it breaks. The command sent to g++ through make was

g++ -DBIGARRAY_MULTIPLIER=1 -Wall -Werror -Wno-unknown-pragmas -D__PIN__=1
-DPIN_CRT=1 -fno-stack-protector -fno-exceptions -funwind-tables
-fasynchronous-unwind-tables -fno-rtti -DTARGET_IA32E -DHOST_IA32E -fPIC
-DTARGET_LINUX -fabi-version=2  -I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/source/include/pin
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/source/include/pin/gen
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/stlport/include
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/libstdc++/include
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include/arch-x86_64
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include/kernel/uapi
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include/kernel/uapi/asm-x86
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/components/include
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/xed-intel64/include
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/source/tools/InstLib -O3
-fomit-frame-pointer -fno-strict-aliasing  -std=c++11 
-c -o obj-intel64/callgraph.o callgraph.cpp

This doesn't compile. Instead, it'll fall into a huge error log inside STL headers. It appears that Pin comes along with it's own subset of STL, that conflicts with C++11 and C++14. I've uploaded a paste of the g++ output. It filled 2331 lines, but I've noticed that strange thing in the folders it visits. STL libraries are included from 2 different directories:

  • /usr/include/c++/5/
  • /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/stlport/include/

Solving errors one-by-one is unfeasible, deleting pin stl port probably is an even worse idea. If it's possible to use Pin with newer C++, I'd say simple std=c++1y is not the way.

Gabriel Vasconcelos
  • 576
  • 5
  • 15
  • Your last question is hinted at by the error message: pass `-std=c++11` to get C++ 2011 support. For C++ 2014 support use `-std=c++14`. – user268396 Sep 25 '16 at 20:52
  • The thing is that Intel Pin demands a huge set of compiler options. Thus they set rules to make it simple via make. I don't know how to include this option in a rule. Still looking for it. – Gabriel Vasconcelos Sep 25 '16 at 20:56
  • 1
    My knowledge is a little out of date but I'd be careful adding any synchronization primitives into the Pintool that didn't come with the Pin kit. Calling them may not work as intended. Instead, use the synchronization primitives provided with the Pin kit, Either PinCRT APIs or link to the sync shared object. – nitzanms Sep 26 '16 at 12:47
  • I know there are some efforts to make Pin work with more advanced C++ - look up Pin++. – nitzanms Sep 26 '16 at 12:47
  • @nitzanms Indeed synchronization directives with such sensitive instruction set is definitely a dangerous thing. I've refrained from using it, but I'm still curious about newer C++ along with Pin, so I decided to keep this discussion running – Gabriel Vasconcelos Sep 26 '16 at 12:58
  • @nitzanms I will have a look at this – Gabriel Vasconcelos Sep 26 '16 at 12:58
  • @nitzanms Were you talking about [this](https://github.com/SEDS/PinPP)? – Gabriel Vasconcelos Sep 26 '16 at 13:03
  • Yes, but now I see that the project scope is different from what I remembered. I don't remember where I saw the C++11 efforts with Pin, sorry. – nitzanms Sep 26 '16 at 15:34

1 Answers1

6

From the compiler options used to compile the pin tool, I presume you are using the latest version of Pin, namely 3.0. According to Intel, the CRT that ships with the framework doesn't support C++11 and later versions of the language. In particular, you will not be able to use any of the APIs supported in C++11 including std::mutex. If it's critical for you to use C++11 APIs then you should use the previous version of Pin, namely 2.14, which doesn't ship with a CRT and uses the CRT of your compiler.

However, if all you want is a mutex, you can use the OS-portable mutex that ships with Pin 3.0. For more information, refer to the documentation.

When using Pin 3.0 you are not allowed to use any header file or object file of your compiler (those from /usr/include/c++/5/). You can only use PinCRT and few system header files.

canihavesomecoffee
  • 163
  • 4
  • 19
Hadi Brais
  • 22,259
  • 3
  • 54
  • 95