I have two llvm::Module objects and needs to combine them programmatically(I know we can dump to bitcode files and run llvm-link on it.)
Using linkInModule() and linkInModules(), I am able to link two modules.
Related
Background:
I have a need of the debugging information of the code in our project.
The following two approaches are available:
Compile using -g and afterwards use GNU binary utilities strip and objcopy to strip the debugging information into a separate file.
Compile using -gsplit-dwarf
Question
The second approach creates a .dwo for each translation unit in the application.
Although this would improve the linker time. But with the huge number of translation files, this would create management headache for us.
Is there a way to combine all the .dwo files into a single file per binary ?
System Info
Compiler : GCC toolchain.
OS: CentOS/RH 7/8
The tool you're looking for is called dwp. It collects your .dwo files into a .dwp file ("DWARF package"). .dwp files can themselves be combined into larger .dwp files if needed.
It should come with non-ancient binutils packages.
I'm searching for a C or C++ library which can load and link obj files (doesn't matter if ELF or obj) dynamicly at runtime. I spend some time searching for such library, but my results weren't successful.
What I tried:
LLVM:
Currently my best solution! I used Clang to generate .obj files in the bytecode format of LLVM and used its JIT functions to dynamic load and execute the function. But, the LLVM is huge and my PC at home hasn't the power to compile the complete LLVM just for the JIT. Also I encountered some problems with relocation overflows or not implemented relocation types.
libjit:
I read, that it can load .elf files and link them too. But sadly, I couldn't compile it for windows, so I couldn't try.
Nanojit and NativeJit:
It seems like they don't support JITting an object file.
So... What can I do? Do I have to stick around with the LLVM? Are there any alternatives?
I suppose that an analogy that can be taken as a 1st approach is that the .bc is similar to an .o (or .obj) file in that it is just the translation of C++ code to an intermediate language, and tht it can contain references to functions not defined in it, to be searched in libraries.
And that the JIT-ted code is similar to a DLL, in the sense that it will be linked dynamically to the executable where it will run in.
You need not to compile LLVM -- you can download the binaries for LLVM and assorted utilities (like clang) from LLVM Download Page
I'm creating an application specifically for the Nintendo Wii using devKitPro. I wanted to make my application modular by offering the ability to load code passed though objcopy -O binary. My problem is, I want the modules to be able to use symbols from the main ELF that is loaded into memory. I have tried various things and I have not come up with any solutions.
I tried use -Map, as I thought that would let me use a linker map with it, but that idea failed.
I also tried compilation into a shared library, but that did not work for me, as the linker complained about "read-only segments with dynamic relocations".
I really need help with this, as I am in neither a Windows or Linux environment.
You may consider doing this using libdl which is made precisely to load symbols by name at runtime. Using libdl you can get handles to all of the functions you want to call as part of an initialization subroutine and then have them available to you when your program needs them. best of all, you dont need to have the library you are linking against at compile time so you can replace it with any elf that has those symbols defined without recompiling.
I recently created two executables from the exact same source code and the exact same path on my computer using GCC version 2.9-gnupro-98r2. When I do a binary compare of the two executables there are differences in the .data section of the executable. Does anyone know why this would happen? I need to produce a consistent executable every time.
Thanks!
It's probably related to timestamp information in the executable. If any of your sources use the __TIME__ macro, the binary executables will be different if you compile at different times.
I'm interested in solutions for the question below for Linux and Windows, GCC, MinGW, and MSVC (if possible).
I have an application that I've written that supports user-defined shared library imports (add on modules). The application scans a directory, finds *.dll files or *.so files, and loads them dynamically at runtime.
So far, all the user modules have been completely composed of self sufficient code. That is, the object files that make up the DLL/SO yielded no incomplete references from the point of view of the linker.
No I want to allow the modules to be able to use functions that are compiled into object files that make up the binary application that is importing these modules. In other words, I want to allow them to use some of my library code, without having to be compiled into the DLL/SO itself. Unfortunately, in the linker phase when building the DLL/SO, this fails with the complaint that there are unresolved symbols.
Is this possible?
Create a library with the code you want to share between the user module and your program.
Now the user program and your program can link with this new library.
why not just make a DLL which is linked by both the main app and all the user libs... this is perfectly legal, safe and does what you want AFAICT.
As for Linux and other ELF platforms, this is perfectly possible. You just need to export the appropriate symbols from your executable, and they will be preferred over the same symbols at the dynamic library. See this question for details.
As suggested by one of the answers to that question, you could instead pass the functions you want to export as callbacks to some initialization function in the dynamic library.
my first thought is: figure out another way to do this... require the add-ons to communicate via a known interface type, and then there will be no need to try to trick the linker...