I have a set of llvm IR byte code object files.
I have found that '-g', option in the llvm-objdump will print the debugging information in the binary.
# llvm-objdump -g llvm-ir-binary.o
but it just only showed the help info , but no any source level debugging information. Is there any other tool or is that the correct option to make it happen ?
Related
I am trying to get LLVM IR for a file which is linked with some static libararies.
I tried to link using llvm-link . It just copy the .bc files in one file ( not like native linking).
clang -L$(T_LIB_PATH) -lpthread -emit-llvm gives an error: emit-llvm can not be used with linking. When passing -c option, it gives warning that the linking options were not used.
My main goal is to get .bc file with all resolved symbols and references. How can I achieve that with clang version 3.4.?
You may have a look at wllvm. It is a wrapper on the compiler, which enable to build a project and extract the LLVM bitcode of the whole program.
You need to use wllvm and wllvm++ for C and C++, respectively (after setting some environment variables).
Some symbols come from source code via LLVM IR. IR is short for intermediate representation. Those symbols are easy to handle, just stop in the middle of the build process.
Some others come from a library and probably were generated by some other compiler, one that never makes any IR, and in any case the compiler was run by some other people at some other location. You can't go back in time and make those people build IR for you, even if their compiler has the right options. All you can do is obtain the source code for the libraries and build your entire application from source.
I'm trying to move a cross-compiled CMake project to Clang Modules to see whether compile time reduction is worth it. However, it seems that Clang is generating lots of duplicate modules in it's ModuleCache.
I'd like to figure out why (maybe some CMake config, etc), so I'm trying to run clang -module-file-info on the generated module files.
However, clang's output is just empty whenever I provide a proper module file. Am I doing anything wrong? Is there anything special that I need to take care of?
The files all have a reasonable size (from a few kB to a few MB), look fine in a Hex editor (start with CPCH, have some recognizable strings, etc) and whenever I specify a wrong file (or a file compiled with a different version of clang) I get the appropriate errors.
I've tried with clang 7.0.1 as well as 8.0.0.
I also tried --verbose but that didn't show any problems either.
To answer my own question:
clang doesn't output the stats on the command line, it puts it into a file by default written in the current directory.
This question already has an answer here:
Building clang taking forever
(1 answer)
Closed 4 years ago.
There was a problem when I've tried to build clang with ninja.I've executed all commands one after another from the link:
http://clang.llvm.org/docs/LibASTMatchersTutorial.html
but after running ninja where the tutorial says "Okay.Now we’ll build Clang!" it takes 2 hours to build half of the objects and after that OS stuck and I couldn't even move the cursor.I did the job on both my laptop and PC but the result was the same.What is attract my attention is that, the size of the folder is so huge (18.3GB).
Is there any way to solve the problem?
I have already answered the same question on StackOverflow here. I will suggest a deeper search in future before asking the same question.
Including information here in case link is lost. What is happening is that building clang in debug mode (that's by default) a lot of debug information is also being generated for each compilation unit the file sizes are becoming big.
The solution is to turn off all the debug info that's been attached by default. You probably are not going to debug clang, so won't need it. So instead of just doing this
cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON
What you should do is
cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release
All the other steps remain the same.
What is the easiest way to produce a Mach-O object file that does not have the SUBSECTIONS_VIA_SYMBOLS flag set, such that the linker (with -dead_strip) will not later try to cut the text section into pieces and guess which pieces are used?
I can use either a command-line option to llvm/gcc (4.2.1) that will prevent it from emitting .subsections_via_symbols in the first place, or a command-line tool that will remove the flag from an existing object file.
(Writing such a tool myself based on the Mach-O spec is an option, but if possible I'd rather not reinvent the wheel that hard).
Platform: iOS, cross-compiling from OSX with XCode 4.5.
Background: We're supplying a static library that other companies build into apps. When our library encounters a problem it produces a crash report with a stack trace and certain other key information that (if we're lucky) we get to analyze later. Typically the apps as deployed have been stripped of debug information so interpreting stack traces is a problem. If we were making the app ourselves we would just save the DWARF debug data from before stripping and use that to decode the addresses in the incoming crash reports. But we can't depend on the app makers supplying us with such data from their linking steps.
What we're doing instead is to let the crash report include the run-time address of selected function; from that we can deduce the offset between addresses in our linker map and addresses in the crash report. We're linking our entire library incrementally into a single .o before we stuff it into an .a; since it does only one big thing there wouldn't be much to save from removing unused functionality from it when the app is eventually linked. Unfortunately there's a few small pieces of code in the library that are sometimes not used (alternative API entry points for the main functionality, small helper functions for interpreting our error codes and the like), and if the app developer links with -dead_strip, it disturbs the address reconstruction of crash reports that the relative offsets in the final app differ from the linker map from our incremental link operation.
We can't realistically ask all app developers to disable dead-code stripping in their build process, so it seems a better way forward if we could mark our .o as "not dead-strippable" and have the eventual app linking respect that.
I solved it.
The output of an incremental link operation only has MH_SUBSECTIONS_VIA_SYMBOLS set if all the input objects have it set. And an object file produced from assembler input only has it set if there's an explicit directive set. So one can remove the flag by linking with an empty assembler input:
echo > empty.s
$(CC) $(CFLAGS) input.o empty.s -nostdlib -Wl,r -o output.o
Background
My goal is to compile OpenCV for ios with support for the armv7s (the s is the hard part) architecture but have been unable to make any progress. My most recent theory is that the problem is that the cmake files that come with the library use gcc as a compiler which I do not think supports armv7s (if I am wrong please tell me). I am completely new to cmake however and have not been able to change the compiler.
The reason I suspect the compiler is because of the line
set (CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_BIT)" CACHE string "Build architecture for iOS")
which as far as I know should include armv7s. Changing that line to
set (CMAKE_OSX_ARCHITECTURES "armv6;armv7;armv7s;i386" CACHE string "Build architecture for iOS")
had no effect.
I know there are explanations of how to set the compiler here, here, and here. My problem is that I am trying to change an existing cmake system and don't know what ramifications my changes could have. The code in question can be downloaded here. To build the framework I run the python script in OpenCV-2.4.2/ios
python build_framework.py ~/Desktop
from what I can tell the relevant cmake files are located in OpenCV-2.4.2/ios/cmake. There are only 3 and all are fairly short. My most recent attempt was to change two lines in the toolchains
CMAKE_FORCE_C_COMPILER (gcc gcc)
CMAKE_FORCE_CXX_COMPILER (g++ g++)
to
SET (DEVROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer")
SET (CC "${DEVROOT}/usr/bin/llvm-gcc-4.2")
SET (CXX "${DEVROOT}/usr/bin/llvm-g++-4.2")
CMAKE_FORCE_C_COMPILER (${CC} CLang)
CMAKE_FORCE_CXX_COMPILER (${CXX} CLang)
in an attempt to copy this SO question.
Question
My first and most important question is if this is out of my depth. I have been assuming that changing the compiler/target architecture would be a simple flag set somewhere but I am becoming less convinced that is true. Also, there is an entire directory OpenCV-2.4.2/cmake filled with much larger cmake files that I have been avoiding in the hopes I don't need to worry about their contents. Is this a problem I am going to be able to solve in less than 10 hours?
If you answered yes to the previous question, can you give me any direction? Suggested reading? Am I justified in ignoring the contents of OpenCV-2.4.2/cmake? I have been shooting in the dark for quite a while now without success.
If it turns out this is as simple as I originally hoped, how do I do it?
Update
I never did figure out how to do this, but there is an xcode version of the library here from which the compiling settings can be changed easily.
Set CMAKE_C_COMPILIER and CMAKE_CXX_COMPILIER to what you need.
Edit: this supposes you already had success with building this for armv7.
Edit2: this will just change the compiler.
I see a lot of links in your question, but didn't find original link with information how to cross compile with CMake.
You should not change anything in existing build system.
In general you need to create toolchain file for your target architecture and run cmake with it.
cmake -DCMAKE_TOOLCHAIN_FILE=< your toolchain file > < path to CMakeLists.txt from opencv >