I'm trying to work on transform passes in LLVM aimed at every OpenMP parallel section which are mentioned using 'omp pragmas'.
I'm thinking something like: Module level, Function level and basic block level, can I write any passes at a parallel loop level. If yes, any directions on this would be really helpful.
Cheers.
There is an open source Implementation of OpenMP support in clang in clang-omp.github.com. It uses Intel's libiomp5 which can be downloaded from openmp.llvm.org
Related
I know both clang (by use target=wasm32) and emscripten can compile C code into webassembly, but how are they different?
It looks like they both use LLVM as backend. Actually, I do not even quite understand the relation between llvm and clang...
I have been reading WebAssembly for a while, but I lack low-level understanding of it. Thank you so much for your time!!
clang is a compiler built on llvm technology so you often hear clang and llvm used interchangeably. clang is a just one component of the llvm project.
emscripten is a compiler that uses clang for most of the heavy lifting of actually compiling to WebAssembly but also add a lot of features and functionality on top of that, mostly related to seamless integration with JavaScript and the web and emulation of POSIX and other standards.
emscripten runs clang internally with --target=wasm32-unknown-emscripten which has some very minor differences to the regular --target=wasm32.
If you run emscripten with -v it will print the full clang command line its uses under the hood.
I am trying to implement a clang tool that does syntactic analysis using ASTMatcher API. I am trying to find out how to specify extra flags for clang to disable semantic checks. I know clang builds a giant AST which includes system headers. Is there any way to parse source code while disabling semantic checks which give rise to unknown type errors? I just want to analyze the syntactic integrity of the source code of the given file. So far, I have tried to get around this problem by modifying the DSL to check whether the matching code is from the main file:
cxxRecordDecl(isExpansionInMainFile()).bind("class");
But this doesn't stop clang from looking into the header files.
Unfortunately, it is impossible to use plain syntactic analysis without sema. The problem is not specifically with clang, but with all of the parsers for C++ out there. Without simultaneous semantic analysis, any syntactic analysis is ambiguous. The issue is properly covered in this answer.
I would like to translate X86_64, x86, ARM executables into LLVM IR (disassembly).
What solution do you suggest ?
mcsema is a production-quality binary lifter. It takes x86 and x86-64 and statically "lifts" it to LLVM IR. It's actively maintained, BSD licensed, and has extensive tests and documentation.
https://github.com/trailofbits/mcsema
Consider using RevGen tool developed within the S2E project. It allows converting x86 binaries to LLVM IR. The source code could be checked out from Revgen branch of GIT repository available by url https://dslabgit.epfl.ch/git/s2e/s2e.git.
As regards to RevGen tool mentioned by #bsa2000, this latest paper "A compiler level intermediate representation based binary analysis and rewriting system" has pointed out some limitations in S2E and Revinc.
I pull them out here.
shortcoming of dynamic translation:
S2E [16] and Revnic [14] present a method for dynamically translating
x86 to LLVM using QEMU. Unlike our approach, these methods convert
blocks of code to LLVM on the fly which limits the application of LLVM
analyses to only one block at a time.
IR incomplete:
Revnic [14] and RevGen [15] recover an IR by merging the translated
blocks, but the recovered IR is incomplete and is only valid for
current execution; consequently, various whole program analyses will
provide incomplete information.
no abstract stack or promoting information
Further, the translated code retains all the assumptions of the
original bi- nary about the stack layout. They do not provide any
methods for obtaining an abstract stack or promoting memory locations
to symbols, which are essential for the application of several
source-level analyses.
I doubt there will be universal solution (think about indirect branches, etc.), LLVM IR is much "higher level" than any assembler. Though it's possible to translate on per-BB basis. You might want to check llvm-qemu and libcpu projects among others.
Just post some references on translating ARM binary to LLVM IR:
disarm - arm binary to llvm ir disassembler
https://code.google.com/p/disarm/
However, I have not tried it, thus not sure about its quality and stability. Anyone else may post additional information about this project?
There is new project, being in some early phases, The libbeauty:
https://github.com/jcdutton/libbeauty
Article about project: Libbeauty: Another Reverse-Engineering Tool, 24 December 2013, Michael Larabel - http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTU
It only supports subset of x86_64 as input now. One of the project goals - is to be able to compile the generated LLVM IR back to assembly to get the binary with same functionality.
Can anybody tell me how to find or create a binding to OpenCV for GNAT?
I want to use Ada2005 to implement some program with OpenCV (1.0 or 2.X),
but I don't know how. Can anybody teach me how to do it?
Teaching you how to create a binding to a complex library is beyond the scope of StackOverflow, but you might start with this tutorial. Then study the relevant GNAT library sources, e.g. Ada.Numerics, and other existing Ada bindings. Among others, Ada 2005 Math Extensions and An Ada binding to the GNU GMP and MPFR Multiple Precision libraries are exemplary as well as accessible.
If you have Gnat Pro (and presumably a support contract from ACT), I think you can get a binding generator from them.
In the comments, Simon Wright pointed out that you can get this binding generator from GCC 4.6.0., which is the official (although sometimes a bit behind) GCC distribution. I generally suggest folks who aren't paying ACT customers get their compiler from GCC, rather than the GNAT GPL version from ACT.
I'm looking at some code compiled for iOS in XCode (so compiled for ARM with gcc) and as far as I can see, the compiler has never used ARM's feature of allowing arbitrary instructions to have a condition attached to them, but instead always branches on a condition as would be the case on Intel and other architectures.
Is this simply a restriction of GCC (I can understand that it might be: that "condition = branch" is embedded at a too high a level in the compiler architecture to allow otherwise), or is there a particular optimisation flag that needs to be turned on to allow compilation of conditional instructions?
(Obviously I appreciate I'm making big assumptions about where use of conditional instructions "ought" to be used and would actually be an optimisation, but I have experience of programming earlier ARM chips and using and analysing the output of Acorn's original ARM C compiler, so I have a rough idea.)
Update: Having investigated this more thanks to the information below, it turns out that:
XCode compiles in Thumb-2 mode, in which conditional execution of arbitrary instructions is not available;
Under some circumstances, it does however use the ITE (if-then-else) instruction to effectively produce instructions with conditional execution.
Seeing some actual assembly would make things clear, but I suspect that the default settings for iOS compilation prefer generation of Thumb code instead of ARM for better code density. While there are pseudo-conditional instructions in Thumb32 aka Thumb-2 (supported in ARMv7 architecture via the IT instruction), the original Thumb16 only has conditional branches. Also, even in ARM mode there are some instructions that cannot be conditional (e.g. many NEON instructions use the extended opcode space with condition field set to NV).
Yes, gcc does not really produce the most optimal code WRT conditional instructions. It works well in the most simple cases, but real code suffers from some pointless slowdowns that can be avoided in hand coded arm ASM. Just to give you a rough idea, I was able to get a 2x speedup for a very low level graphics blit method by doing the read/write and copy logic in ARM asm instead of the C code emitted by gcc. But, keep in mind that this optimization is only worth it for the most heavily used parts of your code. It takes a lot of work to write well optimized ARM asm, so don't even attempt it unless there is a real benefit in the optimization.
The first thing to keep in mind is that xcode uses Thumb mode by default, so in order to generate ARM asm you will need to add the -mno-thumb option to the module specific options for the specific .c file that will contain the ARM asm. Once the ARM asm is getting emitted, you will want to conditionally compile asm statements as indicated in the answer to the following question:
ARM asm conditional compilation question