Loading and storing variables using an LLVM pass - c++

I am trying to do this:
1- Insert a variable t1.
2- Insert a call to the chrono function (to get time).
3- Store chrono's return value in t1
4- Insert a call to "function" (a function I wrote) and pass t1 as its parameter. function does some calculations on t1.
In code it is:
float t1 = std::chrono::duration_cast<chrono::nanoseconds(chrono_steady_clock::now().time_since_epoch().count());
function(t1);
However I want to insert the above with an LLVM pass in a program that I am trying to modify.
I am unsure on how to do it, but my idea is:
Constant *TFunc = M.getOrInsertFunction("std::chrono::duration_cast<chrono::nanoseconds(chrono_steady_clock::now().time_since_epoch().count())", Type::getFloatTy(M.getContext()),NULL);
tfunc = cast<Function>(TFunc);
for (*certain type of instructions Inst*){
CallInst *CurrInst = dyn_cast<CallInst>(Inst);
AllocaInst *Talloc = new AllocaInst(Type::getFloatTy((*Inst).getContext()),"t1");
Instruction *Tcall = CallInst::Create(tfunc,"");
StoreInst* store_t = new StoreInst(Tcall,Talloc,(Instruction*)CurrInst);
if(storeT != NULL) {
LoadInst* loadT = new LoadInst(storeT,"",false);
Value* t1 = loadT;
Instruction *newInst = CallInst::Create(hook,loadT, "");
Inst->getInstList().insert((Instruction*)CurrInst, newInst);
}
}
The error I am getting is:
0 libLLVM-3.4.so.1 0x40f8150f llvm::sys::PrintStackTrace(_IO_FILE*) +
47 1 libLLVM-3.4.so.1 0x40f8177f 2 libLLVM-3.4.so.1 0x40f812ec 3
0x40022400 __kernel_sigreturn + 0 4 libLLVM-3.4.so.1 0x40864ee7
llvm::LoadInst::LoadInst(llvm::Value*, char const*, bool,
llvm::Instruction*) + 71 5 pass.so 0x400265b2 Stack dump:
0. Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name mtd.cc -mrelocation-model pic -pic-level 2 -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.24 -momit-leaf-frame-pointer -g -coverage-file /../mtd.o
-resource-dir /usr/bin/../lib/clang/3.4 -dependency-file .deps/mtd.d -MT mtd.o -sys-header-deps -MP -include config.h -D NDEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D NDEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D NDEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I /usr/lib/llvm-3.4/include -I /usr/lib/llvm-3.4/include -I /usr/lib/llvm-3.4/include
-internal-isystem /usr/include//c++/4.8 -internal-isystem /usr/include//c++/4.8/i386-linux-gnu -internal-isystem
/usr/include//c++/4.8/backward -internal-isystem
/usr/include//i386-linux-gnu/c++/4.8 -internal-isystem
/usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../../include/c++/4.8
-internal-isystem /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../../include/c++/4.8/i686-linux-gnu
-internal-isystem /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../../include/c++/4.8/backward
-internal-isystem /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../../include/i686-linux-gnu/c++/4.8
-internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.4/include -internal-externc-isystem
/usr/bin/../lib/gcc/i686-linux-gnu/4.8/include
-internal-externc-isystem /usr/include/i386-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Woverloaded-virtual -Wcast-qual -W -Wall -w
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir /.../masstree-beta-master
-ferror-limit 19 -fmessage-length 80 -fvisibility-inlines-hidden -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -load /../pass.so
-o mtd.o -x c++ mtd.cc
1. parser at end of file
2. Per-module optimization passes
3. Running pass 'Synchronization profiler' on module 'mtd.cc'. clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to
see invocation) Ubuntu clang version 3.4-1ubuntu3
(tags/RELEASE_34/final) (based on LLVM 3.4) Target: i386-pc-linux-gnu
Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug
report to http://bugs.debian.org/ and include the crash backtrace,
preprocessed source, and associated run script. clang: note:
diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed
source(s) and associated run script(s) are located at: clang: note:
diagnostic msg: /tmp/mtd-7d9a20.cpp clang: note: diagnostic msg:
/tmp/mtd-7d9a20.sh clang: note: diagnostic msg:
******************** make: *** [mtd.o] Error 254
Reading documentations didn't help me much other than producing the above code. I have the following questions:
1- What is wrong with my pass's code? In other words, how to add the code I want to?
2- What does this error mean? I cannot see any meaningful message in it other than there was a segmentation fault and the command couldn't be executed (may be because I am a newbie?).
3- I know how to insert calls to function that I write in another C++ file (like "function") but not to functions but not to functions defined in C++ libraries like this chrono function which is why I wrote "std::chrono::duration_cast
Apologies if my questions are too basic. Help and guidance will be appreciated!

As Instruction inherits from Value in LLVM, after you insert your function as a call instruction you can just pass that instruction to your next function. No need for the load store operations you are trying to do. So call your time function and pass the instruction object you used to call it to "function".

Related

clang-tidy: what might cause NOLINT comments to not be respected?

I've created a PR for the opensource Traffic Server project. They run clang-tidy as a part of their CI. My change exposes a new file to clang-tidy which is now being flagged with a use-after-move warning. Here's the test code, pinned at the commit that my change is based upon:
https://github.com/apache/trafficserver/blob/415cd8f/tests/tools/plugins/test_cppapi.cc#L115
Here's a copy of that code, with a comment added showing where it complains:
void
f()
{
TestCont::Mutex m(TSMutexCreate());
TestCont c(m);
ALWAYS_ASSERT(!!c)
ALWAYS_ASSERT(c.asTSCont() != nullptr)
ALWAYS_ASSERT(c.mutex() == m)
TestCont c2(std::move(c));
ALWAYS_ASSERT(!!c2)
ALWAYS_ASSERT(c2.asTSCont() != nullptr) // <--- Complains here
ALWAYS_ASSERT(c2.mutex() == m)
ALWAYS_ASSERT(!c)
ALWAYS_ASSERT(c.asTSCont() == nullptr)
ALWAYS_ASSERT(c.mutex() == nullptr)
So the complaint makes sense, c2 is used after a move. But in this case, TestCont explicitly supports use after a move by design and the test is intentionally exercising this to make sure its state is as expected.
Thus, this is a situation for which NOLINT and NOLINTNEXTLINE are created. So I applied such comments like this (clearly I've added more comments than I should need to out of desperation):
// NOLINTNEXTLINE
ALWAYS_ASSERT(!c) // NOLINT
// We turn off the clang-tidy warning about this being a use after move
// because that is the intention of the test. Continuations support use after
// move.
// NOLINTNEXTLINE
const auto cont_after_move = c.asTSCont(); // NOLINT
ALWAYS_ASSERT(cont_after_move == nullptr)
// We turn off the clang-tidy warning about this being a use after move
// because that is the intention of the test. Continuations support use after
// move.
// NOLINTNEXTLINE
const auto mutex_after_move = c.mutex(); // NOLINT
ALWAYS_ASSERT(mutex_after_move == nullptr)
Notice that I separated c.asTSCont() as a separate call in case things were being confused by the ALWAYS_ASSERT macro. Yet clang-tidy still complains. Here's the latest jenkins run output:
https://ci.trafficserver.apache.org/job/clang-analyzer-github/12245/console
tools/plugins/test_cppapi.cc:124:32: warning: Method called on moved-from object 'c'
const auto cont_after_move = c.asTSCont(); // NOLINT
^~~~~~~~~~~~
tools/plugins/test_cppapi.cc:151:33: warning: Method called on moved-from object 'c2'
const auto cont2_after_move = c2.asTSCont(); // NOLINT
^~~~~~~~~~~~~
2 warnings generated.
Right there in the warning output is the NOLINT comment. What am I doing wrong? Why isn't clang-tidy respsecting NOLINT?
The clang-tidy version is 10.0.0. Here's the clang-analyzer report in case it's helpful:
https://ci.trafficserver.apache.org/clang-analyzer/github/6945/2020-06-25-081635-12865-1/report-33708c.html#EndPath
Here's a copy and paste of the clang-tidy invocation:
clang -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test_cppapi.cc -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-checker=core -analyzer-checker=apiModeling -analyzer-checker=unix -analyzer-checker=deadcode -analyzer-checker=cplusplus -analyzer-checker=security.insecureAPI.UncheckedReturn -analyzer-checker=security.insecureAPI.getpw -analyzer-checker=security.insecureAPI.gets -analyzer-checker=security.insecureAPI.mktemp -analyzer-checker=security.insecureAPI.mkstemp -analyzer-checker=security.insecureAPI.vfork -analyzer-checker=nullability.NullPassedToNonnull -analyzer-checker=nullability.NullReturnedFromNonnull -analyzer-output plist -w -setup-static-analyzer -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-feature +cx16 -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir /opt/llvm/lib64/clang/10.0.0 -D HAVE_CONFIG_H -I . -I ../include -D linux -D _LARGEFILE64_SOURCE=1 -D _COMPILE64BIT_SOURCE=1 -D _REENTRANT -D __STDC_LIMIT_MACROS=1 -D __STDC_FORMAT_MACROS=1 -I /var/jenkins/workspace/clang-analyzer-github/src/proxy/api -I /var/jenkins/workspace/clang-analyzer-github/src/proxy/api -I /var/jenkins/workspace/clang-analyzer-github/src/include/cppapi/include -I /var/jenkins/workspace/clang-analyzer-github/src/lib/cppapi/include -I /var/jenkins/workspace/clang-analyzer-github/src/include -I /var/jenkins/workspace/clang-analyzer-github/src/lib -D _GNU_SOURCE -D OPENSSL_NO_SSL_INTERN -I /opt/llvm/include/c++/v1 -D PIC -internal-isystem /opt/llvm/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /opt/llvm/lib64/clang/10.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Wno-deprecated-declarations -Wno-ignored-qualifiers -Wno-unused-parameter -Wno-invalid-offsetof -std=c++17 -fdeprecated-macro -fdebug-compilation-dir /var/jenkins/workspace/clang-analyzer-github/src/tests -ferror-limit 19 -fmessage-length 0 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -analyzer-checker alpha.unix.cstring.BufferOverlap -analyzer-checker alpha.core.BoolAssignment -analyzer-checker alpha.core.CastSize -analyzer-checker alpha.core.SizeofPtr -analyzer-output=html -faddrsig -o /CA/clang-analyzer/github/6945/2020-06-25-081635-12865-1 -x c++ tools/plugins/test_cppapi.cc
In the end I was confused between clang-tidy and clang-analyzer. NOLINT addresses clang-tidy issues, but I had to suppress clang-analyzer. I did so using the suggestion here:
https://clang-analyzer.llvm.org/faq.html#exclude_code
The following directives quieted the warnings for me:
#ifndef __clang_analyzer__
// Code not to be analyzed
#endif

compiles a c++ file that includes clang/AST libraries in ubuntu16.0.4

I am new to c++. Today, I installed llvm, clang and libc++ as https://clang.llvm.org/get_started.html instructed.
$ llvm-config --version
6.0.0svn-r311975
$ clang --version
clang version 6.0.0 (trunk 311975)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jzhu/build/bin
I tried to follow the example http://clang.llvm.org/docs/RAVFrontendAction.html by creating files called FindClassDecls.cpp and CMakeLists.txt The only difference is I used <> instead of "" to include the clang header files.
Then when I tried to compile the .ccp file with
clang++ -v -std=c++11 -stdlib=libc++ -I/home/jzhu/llvm/tools/clang/include -I/home/jzhu/llvm/include -I/home/jzhu/build/include -I/home/jzhu/build/tools/clang/include -L/home/jzhu/build/lib FindClassDecls.cpp
It gives
clang version 6.0.0 (trunk 311975)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jzhu/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;#m64
Selected multilib: .;#m64
"/home/jzhu/build/bin/clang-6.0" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name FindClassDecls.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /home/jzhu/build/lib/clang/6.0.0 -I /home/jzhu/build/include -I /home/jzhu/build/tools/clang/include -internal-isystem /home/jzhu/build/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /home/jzhu/build/lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/jzhu/sandbox -ferror-limit 19 -fmessage-length 140 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/FindClassDecls-71cf4e.o -x c++ FindClassDecls.cpp
clang -cc1 version 6.0.0 based upon LLVM 6.0.0svn-r311975 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/home/jzhu/build/include
/home/jzhu/build/tools/clang/include
/home/jzhu/build/bin/../include/c++/v1
/usr/local/include
/home/jzhu/build/lib/clang/6.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
"/usr/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0 -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../.. -L/home/jzhu/build/bin/../lib -L/lib -L/usr/lib /tmp/FindClassDecls-71cf4e.o -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crtn.o
/tmp/main-3a7b68.o: In function `main':
main.cpp:(.text+0xa0): undefined reference to `clang::tooling::runToolOnCode(clang::FrontendAction*, llvm::Twine const&, llvm::Twine const&, std::__1::shared_ptr<clang::PCHContainerOperations>)'
/tmp/main-3a7b68.o: In function `clang::ASTFrontendAction::ASTFrontendAction()':
main.cpp:(.text._ZN5clang17ASTFrontendActionC2Ev[_ZN5clang17ASTFrontendActionC2Ev]+0x1b): undefined reference to `clang::FrontendAction::FrontendAction()'
main.cpp:(.text._ZN5clang17ASTFrontendActionC2Ev[_ZN5clang17ASTFrontendActionC2Ev]+0x21): undefined reference to `vtable for clang::ASTFrontendAction'
/tmp/main-3a7b68.o: In function `clang::ASTConsumer::ASTConsumer()':
main.cpp:(.text._ZN5clang11ASTConsumerC2Ev[_ZN5clang11ASTConsumerC2Ev]+0x6): undefined reference to `vtable for clang::ASTConsumer'
/tmp/main-3a7b68.o: In function `clang::RecursiveASTVisitor<FindNamedClassVisitor>::TraverseCapturedDecl(clang::CapturedDecl*)':
...
more undefined reference errors
...
/tmp/main-3a7b68.o:(.data+0x0): undefined reference to `llvm::EnableABIBreakingChecks'
/tmp/main-3a7b68.o:(.rodata._ZTV20FindNamedClassAction[_ZTV20FindNamedClassAction]+0x28): undefined reference to `clang::ASTFrontendAction::ExecuteAction()'
/tmp/main-3a7b68.o:(.rodata._ZTV20FindNamedClassAction[_ZTV20FindNamedClassAction]+0x38): undefined reference to `clang::FrontendAction::shouldEraseOutputFiles()'
/tmp/main-3a7b68.o:(.rodata._ZTI20FindNamedClassAction[_ZTI20FindNamedClassAction]+0x10): undefined reference to `typeinfo for clang::ASTFrontendAction'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x28): undefined reference to `clang::ASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef)'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x38): undefined reference to `clang::ASTConsumer::HandleInterestingDecl(clang::DeclGroupRef)'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x60): undefined reference to `clang::ASTConsumer::HandleTopLevelDeclInObjCContainer(clang::DeclGroupRef)'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x68): undefined reference to `clang::ASTConsumer::HandleImplicitImportDecl(clang::ImportDecl*)'
/tmp/main-3a7b68.o:(.rodata._ZTI22FindNamedClassConsumer[_ZTI22FindNamedClassConsumer]+0x10): undefined reference to `typeinfo for clang::ASTConsumer'
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Questions:
Do I suppose to build the .cpp file with such arguments?
How to avoid manually enter the path to the header files every time I run the clang++ compiler.
Have I done something wrong?
Do I need a -L for which library do I need to link (crt1.o? crti.o?)
/home/jzhu/build/lib$ ls
Analysis libc++.so.1.0
libLLVMHexagonInfo.a libLLVMSparcCodeGen.a AsmParser
libDynamicLibraryLib.a libLLVMInstCombine.a
libLLVMSparcDesc.a BinaryFormat libgtest.a
libLLVMInstrumentation.a libLLVMSparcDisassembler.a Bitcode
libgtest_main.a libLLVMInterpreter.a
libLLVMSparcInfo.a BugpointPasses.so
libLLVMAArch64AsmParser.a libLLVMipo.a
libLLVMSupport.a clang
libLLVMAArch64AsmPrinter.a libLLVMIRReader.a
libLLVMSymbolize.a cmake
libLLVMAArch64CodeGen.a libLLVMLanaiAsmParser.a
libLLVMSystemZAsmParser.a CMakeFiles
libLLVMAArch64Desc.a libLLVMLanaiAsmPrinter.a
libLLVMSystemZAsmPrinter.a cmake_install.cmake
libLLVMAArch64Disassembler.a libLLVMLanaiCodeGen.a
libLLVMSystemZCodeGen.a CodeGen
libLLVMAArch64Info.a libLLVMLanaiDesc.a
libLLVMSystemZDesc.a DebugInfo
libLLVMAArch64Utils.a libLLVMLanaiDisassembler.a
libLLVMSystemZDisassembler.a Demangle
libLLVMAMDGPUAsmParser.a libLLVMLanaiInfo.a
libLLVMSystemZInfo.a ExecutionEngine
libLLVMAMDGPUAsmPrinter.a libLLVMLibDriver.a
libLLVMTableGen.a FuzzMutate
libLLVMAMDGPUCodeGen.a libLLVMLineEditor.a
libLLVMTarget.a IR libLLVMAMDGPUDesc.a
libLLVMLinker.a libLLVMTestingSupport.a IRReader
libLLVMAMDGPUDisassembler.a libLLVMLTO.a
libLLVMTransformUtils.a libc++.a
libLLVMAMDGPUInfo.a libLLVMMC.a
libLLVMVectorize.a libc++abi.a
libLLVMAMDGPUUtils.a libLLVMMCDisassembler.a
libLLVMWindowsManifest.a libc++abi.so
libLLVMAnalysis.a libLLVMMCJIT.a
libLLVMX86AsmParser.a libc++abi.so.1
libLLVMARMAsmParser.a libLLVMMCParser.a
libLLVMX86AsmPrinter.a libc++abi.so.1.0
libLLVMARMAsmPrinter.a libLLVMMipsAsmParser.a
libLLVMX86CodeGen.a libc++experimental.a
libLLVMARMCodeGen.a libLLVMMipsAsmPrinter.a
libLLVMX86Desc.a libclangAnalysis.a libLLVMARMDesc.a
libLLVMMipsCodeGen.a libLLVMX86Disassembler.a
libclangARCMigrate.a libLLVMARMDisassembler.a
libLLVMMipsDesc.a libLLVMX86Info.a libclangAST.a
libLLVMARMInfo.a libLLVMMipsDisassembler.a
libLLVMX86Utils.a libclangASTMatchers.a libLLVMARMUtils.a
libLLVMMipsInfo.a libLLVMXCoreAsmPrinter.a libclangBasic.a
libLLVMAsmParser.a libLLVMMIRParser.a
libLLVMXCoreCodeGen.a libclangCodeGen.a
libLLVMAsmPrinter.a libLLVMMSP430AsmPrinter.a
libLLVMXCoreDesc.a libclangDriver.a
libLLVMBinaryFormat.a libLLVMMSP430CodeGen.a
libLLVMXCoreDisassembler.a libclangDynamicASTMatchers.a
libLLVMBitReader.a libLLVMMSP430Desc.a
libLLVMXCoreInfo.a libclangEdit.a
libLLVMBitWriter.a libLLVMMSP430Info.a
libLLVMXRay.a libclangFormat.a libLLVMBPFAsmPrinter.a
libLLVMNVPTXAsmPrinter.a libLTO.so libclangFrontend.a
libLLVMBPFCodeGen.a libLLVMNVPTXCodeGen.a
libLTO.so.6 libclangFrontendTool.a libLLVMBPFDesc.a
libLLVMNVPTXDesc.a libLTO.so.6.0.0svn libclangIndex.a
libLLVMBPFDisassembler.a libLLVMNVPTXInfo.a LineEditor
libclangLex.a libLLVMBPFInfo.a
libLLVMObjCARCOpts.a Linker libclangParse.a
libLLVMCodeGen.a libLLVMObject.a
LLVMHello.so libclangRewrite.a libLLVMCore.a
libLLVMObjectYAML.a LTO libclangRewriteFrontend.a
libLLVMCoroutines.a libLLVMOption.a Makefile
libclangSema.a libLLVMCoverage.a
libLLVMOrcJIT.a MC libclangSerialization.a
libLLVMDebugInfoCodeView.a libLLVMPasses.a Object
libclang.so libLLVMDebugInfoDWARF.a
libLLVMPowerPCAsmParser.a ObjectYAML libclang.so.6
libLLVMDebugInfoMSF.a libLLVMPowerPCAsmPrinter.a Option
libclang.so.6.0 libLLVMDebugInfoPDB.a
libLLVMPowerPCCodeGen.a Passes libclangStaticAnalyzerCheckers.a
libLLVMDemangle.a libLLVMPowerPCDesc.a
ProfileData libclangStaticAnalyzerCore.a libLLVMDlltoolDriver.a
libLLVMPowerPCDisassembler.a Support libclangStaticAnalyzerFrontend.a
libLLVMExecutionEngine.a libLLVMPowerPCInfo.a TableGen
libclangTooling.a libLLVMFuzzMutate.a
libLLVMProfileData.a Target libclangToolingASTDiff.a
libLLVMGlobalISel.a libLLVMRuntimeDyld.a Testing
libclangToolingCore.a libLLVMHexagonAsmParser.a
libLLVMScalarOpts.a ToolDrivers libclangToolingRefactor.a
libLLVMHexagonCodeGen.a libLLVMSelectionDAG.a Transforms
libc++.so libLLVMHexagonDesc.a
libLLVMSparcAsmParser.a WindowsManifest libc++.so.1
libLLVMHexagonDisassembler.a libLLVMSparcAsmPrinter.a XRay
ps: I installed llvm in my home folder e.g. ~/llvm and ~/build for more details please see the arguments that I passed in to help the compiler find those header files above.
Much appreciated for any suggestion that can point me to the right direction.

Xcode C++ Project - Set custom entry point [duplicate]

I have the following program:
#include <stdio.h>
int bob() {
printf("bob\n");
return 0;
}
int main() {
printf("main\n");
return 0;
}
On Linux, I can enable a custom entry point via:
gcc test.c -Wl,-e,bob
When I run the resulting program, I get:
./a.out
bob
On OS X, however, this doesn't work:
clang test.c -Wl,-e,bob
./a.out
main
I've tried everything to get this to work. I think it might be a bug. Here's the output with the -v option:
clang test.c -Wl,-e,bob -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1 -fdebug-compilation-dir /Users/mfichman/jogo -ferror-limit 19 -fmessage-length 125 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -x c test.c
clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.3.0
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -e bob -o a.out /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
You can see that clang is correctly passing -e to ld, so maybe this is a problem with Apple's ld. If that's the case, I'd be interested in workaround solutions.
The default entry point overridden by the -e argument is not _main but rather start, which is responsible for setting up and calling _main, then passing the return value of _main to _exit. If you specify your own entry point you'll need to perform these steps yourself. There's currently no way to have this initialization performed for you but use a different main function as use of _main is hard-coded into the tools.
The reason your -e argument is ignored is due to a change in 10.8. Prior to this release the implementation of start was linked into each application via crt1.o. In 10.8 the start processing can be performed by dyld and the LC_MAIN load command specifies the offset to the main function within the program. Changing this offset appears to be what you want, but this is not currently possible as when the LC_MAIN startup method is used ld always uses _main and disregards the -e argument. To specify your own entry point you need to tell ld to use the old method of program startup, which you can do for an application with a deployment target of 10.8 or later by passing -no_new_main to the linker. This is the default behavior for applications with a deployment target earlier than 10.8.

Clang doesnt recognize std::all_of in <algorithm>

while compiling in our test environment i encountered the following problem:
Despite the already working windows our build failed on Freebsd 9 with the following error message:
error: no member named 'all_of' in namespace 'std'
Given that i added -std=c++11 to our Cmake flags i wonder why this is not working.
clang version 3.4 (tags/RELEASE_34/final)
Target: i386-portbld-freebsd9.1
Thread model: posix
Heres the function
#include <algorithm>
...
inline bool is_positive_number(const std::string & str)
{
if (str.empty())
return false;
return std::all_of(str.begin(), str.end(), ::isdigit);
}
Installer Log from pkg install clang34
Installing libexecinfo: 1.1_3
Installing llvm34: 3.4_1
Installing clang34: 3.4_2
Help appreciated i thought this function was implemented some ages ago but apparently im using it wrong or maybe i totally misunderstood something both is possible im quite new to clang.
Edit: Details of the process.
Selected GCC installation:
"/usr/local/llvm34/bin/clang" -cc1 -triple i386-portbld-freebsd9.1 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version 2.17.50 -v -v -g -coverage-file /home/source/release/server/game/CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -resource-dir /usr/local/llvm34/bin/../lib/clang/3.4 -D "__SVN_VERSION__=\"\"" -I /home/source/release/server/game/../../extern/include/boost -I /home/source/release/server/game/../../extern/include -I /home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include -I /home/source/release/server/game/../liblua/include -I /home/source/release/server/game/../libdevil -internal-isystem /usr/include/c++/4.2 -internal-isystem /usr/include/c++/4.2/backward -Wno-invalid-source-encoding -W -Wno-invalid-source-encoding -W -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/source/release/server/game -ferror-limit 19 -fmessage-length 237 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -x c++ /home/source/release/server/game/src/main.cpp
clang -cc1 version 3.4 based upon LLVM 3.4 default target i386-portbld-freebsd9.1
ignoring duplicate directory "/usr/include/c++/4.2"
ignoring duplicate directory "/usr/include/c++/4.2"
ignoring duplicate directory "/usr/include/c++/4.2/backward"
#include "..." search starts here:
#include <...> search starts here:
/home/source/release/server/game/../../extern/include/boost
/home/source/release/server/game/../../extern/include
/home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include
/home/source/release/server/game/../liblua/include
/home/source/release/server/game/../libdevil
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/local/llvm34/bin/../lib/clang/3.4/include
After switching to "-stdlib=libc++" as suggested by Steve Wills, I assume its selecting the right include path (v1) but its still not found or conflicted.
clang version 3.4 (tags/RELEASE_34/final)
Target: i386-portbld-freebsd9.1
Thread model: posix
Selected GCC installation:
"/usr/local/llvm34/bin/clang" -cc1 -triple i386-portbld-freebsd9.1 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version 2.17.50 -v -v -g -coverage-file /home/source/release/server/game/CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -resource-dir /usr/local/llvm34/bin/../lib/clang/3.4 -D "__SVN_VERSION__=\"\"" -I /home/source/release/server/game/../../extern/include/boost -I /home/source/release/server/game/../../extern/include -I /home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include -I /home/source/release/server/game/../liblua/include -I /home/source/release/server/game/../libdevil -internal-isystem /usr/include/c++/v1 -Wno-invalid-source-encoding -W -Wno-invalid-source-encoding -W -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/source/release/server/game -ferror-limit 19 -fmessage-length 237 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -x c++ /home/source/release/server/game/src/main.cpp
clang -cc1 version 3.4 based upon LLVM 3.4 default target i386-portbld-freebsd9.1
ignoring duplicate directory "/usr/include/c++/4.2"
#include "..." search starts here:
#include <...> search starts here:
/home/source/release/server/game/../../extern/include/boost
/home/source/release/server/game/../../extern/include
/home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include
/home/source/release/server/game/../liblua/include
/home/source/release/server/game/../libdevil
/usr/include/c++/v1
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/local/llvm34/bin/../lib/clang/3.4/include
/usr/include
End of search list.
In file included from /home/source/release/server/game/src/main.cpp:1:
In file included from /home/source/release/server/game/src/stdafx.h:12:
/home/source/release/server/game/src/../../common/utils.h:120:14: error: no member named 'all_of' in namespace 'std'
This error is likely a result of a missing:
set( CMAKE_CXX_STANDARD 11 )
It would appear that there is something in your Cmake setup.
Or maybe that Cmake isn't very good at recognizing Clang?
The following minimal example;
#include <algorithm>
#include <string>
bool is_positive_number(const std::string & str);
int main(int argc, char *argv[]) {
is_positive_number("12");
}
bool is_positive_number(const std::string & str)
{
if (str.empty())
return false;
return std::all_of(str.begin(), str.end(), ::isdigit);
}
compiles without warnings using c++ or clang++ without any special directives;
c++ -Wall foo.cpp
For reference (reformatted for convenience):
c++ -### foo.cpp
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
Target: x86_64-unknown-freebsd10.0
Thread model: posix
"/usr/bin/c++" "-cc1" "-triple" "x86_64-unknown-freebsd10.0"
"-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier"
"-main-file-name" "foo.cpp" "-mrelocation-model" "static"
"-mdisable-fp-elim"
"-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
"-target-cpu" "x86-64" "-resource-dir" "/usr/bin/../lib/clang/3.4"
"-internal-isystem" "/usr/include/c++/v1" "-fdeprecated-macro"
"-fdebug-compilation-dir" "/home/rsmith/tmp" "-ferror-limit" "19"
"-fmessage-length" "105" "-mstackrealign" "-fobjc-runtime=gnustep"
"-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option"
"-fcolor-diagnostics" "-vectorize-slp" "-o" "/tmp/foo-206692.o"
"-x" "c++" "foo.cpp"
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker"
"/libexec /ld-elf.so.1" "--hash-style=both" "--enable-new-dtags"
"-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o"
"/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/foo-206692.o"
"-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
"-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
"/usr/lib/crtend.o" "/usr/lib/crtn.o"
Notice how this only uses "-internal-isystem" "/usr/include/c++/v1", while your invocation also uses /usr/include/c++/4.2" (which is from the old GCC c++ version 4.2).
to run all_of function you need c++11 complier
if you run the program in codeblocks then go to
setting --> compliers --> c++11 ISO c++ language standard [-std=c++11]
it will surely work
thank you good luck

Is boost reliable when it gives such an error? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Here is the kind of errors I get, that is definitely not related to my code
/usr/bin/c++ -D_TIMER -g -I/usr/local/Cellar/boost/1.54.0/include -I/Users/issam/include -o output.o -c project.cpp
In file included from project.cpp:756:
In file included from /Users/issam/include/project.hpp:123:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex.hpp:31:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/regex.hpp:39:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/regex_traits.hpp:27:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/regex_traits.hpp:39:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/cpp_regex_traits.hpp:40:
/usr/local/Cellar/boost/1.54.0/include/boost/regex/pending/object_cache.hpp:39:17: error: no type named 'list' in namespace 'std'
typedef std::list<value_type> list_type;
~~~~~^
if I compile a file that only includes:
#include "boost/regex.hpp"
It compiles without any problem and creates the .o file. Here is the verbose output of the compilation
/usr/bin/c++ -D_TIMER -g -I/usr/local/Cellar/boost/1.54.0/include -o output.o -c newFile.cpp -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name newFile.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -g -coverage-file /Users/issam/folder/output.o -resource-dir /usr/bin/../lib/clang/4.2 -D _TIMER -I /usr/local/Cellar/boost/1.54.0/include -fmodule-cache-path /var/folders/pd/kcfk19hd5mv9vjwsvpqtk_tc0000gq/T/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir /Users/issam/folder -ferror-limit 19 -fmessage-length 168 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o output.o -x c++ newFile.cpp
clang -cc1 version 4.2 based upon LLVM 3.2svn default target x86_64-apple-darwin12.5.0
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
ignoring nonexistent directory "/usr/include/c++/4.0.0"
ignoring nonexistent directory "/usr/include/c++/4.0.0/i686-apple-darwin8/"
ignoring nonexistent directory "/usr/include/c++/4.0.0/backward"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/boost/1.54.0/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/usr/bin/../lib/clang/4.2/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
boost/regex/pending/object_cache.hpp has the following on line 23:
#include <list>
so for an error such as "error: no type named 'list' in namespace 'std'", it seems likely that your installation of Boost or your compiler toolchain has a problem.
What happens if you try to compile a C++ source file that contains only:
#include "boost/regex.hpp"
I looked it up - the mentioned header file includes <list>, so everything is ok there.
Chances are that you messed up the namespaces by including either boost/regex.hpp or your own project.hpp inside a namespace or by using directives before the #include of either header.
The compiler tells you about an error at the location where it actually sees there was an error, in this case somewhere deep in the guts of the boost headers. Often, when an error is made, you don't notice it immediately, but much later when things look screwed up. It's the same for the compiler this time. It can't say exactly where you messed up, but only how it knows something is wrong.