I am building LLVM with cmake and Ninja build generator as following:
cmake path/to/llvm/ -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=1 -DLLVM_ENABLE_CXX1Y=1 -DLLVM_ENABLE_RTTI=1 -DLLVM_TARGETS_TO_BUILD="X86" -G Ninja
Now I a am trying to use the -debug-only=mytype option of opt to print some debug information about my own passes: using the following in my passes code:
define DEBUG_TYPE "mytype"
DEBUG(errs() << "My debug message\n");
Running opt as following doesn't generate any output messages:
opt < a.bc > /dev/null -mypass -debug-only=mytype
According to LLVM documentation:
For performance reasons, -debug-only is not available in optimized build (--enable-optimized) of LLVM.
I suspect this to be the root of my issue, but I can't find how to turn on/off this option when using cmake to build llvm.
It is controlled by enabling assertions.
cmake -DLLVM_ENABLE_ASSERTIONS=ON is enough to turn it on. If you don't see your debug output, then your code is not executed.
I am adding here a complement answer to my question. As #Joky said, cmake -DLLVM_ENABLE_ASSERTIONS=ON must be specified when compiling llvm. Also, because my passes are built outside the llvm source tree, assertions must also be enabled when building the passes.
Related
I am using "Support/Debug.h" to introduce debug statements in my pass. In order to enable the debug mode, I am required to run opt with the -debug flag, however opt has no such flag.
opt: Unknown command line argument '-debug'. Try: 'opt -help'
opt: Did you mean '-debugify'?
I tried both with the releasebuild and the debugBuild version of the opt binary.
It looks like the -debug flag does not exist if you build llvm with the NDEBUG macro set, which I assume most versions shipped with Linux distros will do. I haven't tested, but you probably have to build llvm from source if you haven't already done so.
You need a debug build of LLVM (i.e. opt) and your pass (i.e. use -DCMAKE_BUILD_TYPE=Debug instead of -DCMAKE_BUILD_TYPE=Release)
I am trying to build openvibe! source code on raspbian and i have installed all the required dependencies, one by one manually, but in the end it seems to have a compilation error.
So after writing build files it says:
-- Build files have been written to: /home/pi/Desktop/openvibe-2.0.0-src/build/sdk-Release
Generation succeeded!
Building project...
and:
[1/340] Building CXX object build-tool...
[some dirty code here]
and then stops building sdk
returning this :
c++: error: unrecognized command line option ‘-msse2’
ninja: build stopped: subcommand failed.
ERROR: Build failed
Error while building sdk
I want to make it clear that i have searched everywhere and SOF is my last resort! So any help would be highly appreciated!
Judging by the output, you are building the library using cmake.
-msse2 is gcc compilation flag, which enables x86 sse vectorisation. Since you are compiling for raspbian you need to disable it.
Usually, compilation flags are set in CMakeLists.txt files. Find, the place where it was set:
find . -name CMakeLists.txt | xargs grep msse2
You will find something like:
# Switch -msse2 enables vectorization. Remove if your CPU/compiler doesn't support it.
SET(OV_EIGEN_FLAGS "-msse2")
As guided, remove every occurrence, and you are done.
I am trying to compile kernel for Cyanogenmod 13. I am getting error
ERROR: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
To build the kernel despite the mismatches, build with:
'make CONFIG_NO_ERROR_ON_MISMATCH=y'
(NOTE: This is not recommended)
I read it here. That i need to compile my kernel using 4.7.
How can i choose the version of toolchain during cyanogenmod build ??
I believe you need to setup gcc version 4.7 and use CC variable to set it as a compiler. E.g. make target CC=/bin/gcc4.7
More information here and here.
Thanks to #nopasara and his valuable comment.
So i did little research further and discovered that the kernel is compatiable with arm-eabi tool chain not arm-linux-androideabi toolchain. So here is the command i used
export PATH=$PATH:~/android/system/prebuilts/gcc/linux-x86/arm/arm-linux-eabi-4.7/bin/ && export ARCH=arm && export SUBARCH=arm && export CROSS_COMPILE=arm-linux-eabi- && make msm8226_defconfig O=~/android/system/out/target/product/E6790/obj/KERNEL_OBJ
and
make O=~/android/system/out/target/product/E6790/obj/KERNEL_OBJ zImage -j4
To do with this Cyanogenmod add following line to your BoardConfig.mk
TARGET_KERNEL_CROSS_COMPILE_PREFIX := arm-eabi-
and either use
export TARGET_LEGACY_GCC_VERSION=4.7
Or edit ~/android/system/build/core/combo/TARGET_linux-arm.mk and set version in
$(combo_2nd_arch_prefix)TARGET_LEGACY_GCC_VERSION := 4.7
How can I increase the verbosity of the build process?
Bazel seems to print compiler commands only if something goes wrong during the build.
I would like to see which compiler comands the cc_library rule fires, even if everything seems to be fine, to debug linking problems.
I already tried various bazel command line parameters but nothing gives me the compiler commands :(
This is probably what you are looking for:
bazel build --subcommands //my:target
The --subcommands option causes Bazel's execution phase to print the full command line for each command prior to executing it.
Useful information taken from Envoy's bazel readme (https://github.com/envoyproxy/envoy/blob/master/bazel/README.md)
When trying to understand what Bazel is doing, the -s and --explain options are useful. To have Bazel provide verbose output on which commands it is executing:
bazel build -s //source/...
To have Bazel emit to a text file the rationale for rebuilding a target:
bazel build --explain=file.txt //source/...
To get more verbose explanations:
bazel build --explain=file.txt --verbose_explanations //source/...
Maybe you can generate the compile_commands.json file. I have created Shell scripts (under Linux) to automate that: https://github.com/vincent-picaud/Bazel_and_CompileCommands.
You might also find the following useful in addition to the accepted answer of using --subcommands (-s):
bazel build --subcommands --verbose_failures //my:target
The --verbose_failures option causes Bazel's execution phase to print the full command line for commands that failed.
Although it would seem the --subcommands option supercedes it given it is documented to display prior to command execution, I have found cases (with bazel 5.2.0) where for a failing command, --subcommands alone shows only a portion of the command along with <remaining N arguments skipped>. Using both --subcommands and --verbose_failures displays the full command line in these cases.
I need some simple example to start using clang.
I downloaded llvm and clang and built:
mkdir llvm-build
cd llvm-build
../llvm/configure
make
I tried to build PrintFunctionNames from clang examples but got an error message:
../../../../Makefile.common:61: ../../../../Makefile.config: No such file or directory
../../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: * No rule to make target `/Makefile.rules'. Stop.
Readme file says that only make is needed.
So how to build this plugin?
Go into llvm-build/tools/clang, and run "make BUILD_EXAMPLES=1".
Most assuredly you will have your LLVM trunk checkout and under the tools path you have checked out Clang trunk as well [explained under building Clang via http://clang.llvm.org/get_started.html.
Makefile Build Guide: http://llvm.org/docs/MakefileGuide.html
On OS X the build set up is a bit different, but on Debian Linux I'm building it daily as follows:
../trunk/configure --enable-target=x86_64,arm,cpp,cbe --with-built-clang --enable-pic --enable-polly --enable-shared --with-cxx-include-arch=x86_64 --enable-optimized --with-optimize-option=-Os --enable-assertions --disable-bootstrap --disable-multilib --enable-jit --enable-threads --no-create --no-recursion
then applying the make -j (n+1 number of cores) on the command for my Pentium D 945 system:
make [building against autotools make -j (n+1) doesn't always building llvm cleanly as it does against cmake. So if you want to run all cores, expect the possibility of running make -j(n+1) more than once to result in a clean build.
Standard form without accessing multiple cores:
make BUILD_EXAMPLES='1' //Read the note below
always results in a clean build, and if it doesn't report a bug to LLVM.
Note: If you're at the top level you can svn update the llvm trunk, project-test trunk and clang trunk as follows:
make trunk
Then go and run make again now that BUILD_EXAMPLES=1 is configured ahead of time.
make BUILD_EXAMPLES='1'
NOTE: Autotools will allow one to configure the BUILD_EXAMPLES='1' but will ignore the flag when you go to run make if you don't explicitly include BUILD_EXAMPLES='1' after make on the command line.
At the top of the LLVM tree you build against running make BUILD_EXAMPLES='1' will build the LLVM specific examples, then going inside your build/tools/clang path you then must run make BUILD_EXAMPLES='1' again to build the Clang examples.
Hence:
LLVM Top:
make BUILD_EXAMPLES='1' // for LLVM examples
cd tools/clang
make BUILD_EXAMPLES='1' // for Clang specific examples
Verify the examples installing under /usr/local/bin for LLVM and /usr/local/lib/ for Clang.
If you use CMAKE the default location for the binary examples is under /usr/local/examples
I followed the instructions at http://clang.llvm.org/get_started.html with two exceptions:
My build dir is inside the source dir (i.e. cd llvm ; mkdir build), but I don't think it's relevant.
I issued cmake as so :
cd build
cmake -DLLVM_BUILD_EXAMPLES=1 -DCLANG_BUILD_EXAMPLES=1 ..
After that (and compiling of course (make -j8)) I could find the examples in the build dir :
find -iname '*printfunctionname*'
./lib/PrintFunctionNames.so
...
I tried to do something similar yesterday: get a list of methods in a class using clang and succeeded. Maybe my post helps here also. My best help was this AST Matchers tutorial.