I compiled LLVM 6.0.0 on Windows for x64 as a DLL, and tried running the HowToUseJit example program, and it seg faulted. How do you fix it?
Source code for the example:
https://github.com/llvm-mirror/llvm/blob/release_60/examples/HowToUseJIT/HowToUseJIT.cpp
This line was causing the seg fault in the example:
GenericValue gv = EE->runFunction(FooF, noargs);
I think the HowToUseJit example is incomplete. You need to make the following changes in order to make it work:
Add the following include:
#include "llvm/ExecutionEngine/MCJIT.h"
This will call some static initializer function which is required for JITting to work in LLVM.
You also need to add a call to this function inside main before running the JITted function:
LLVMInitializeNativeAsmPrinter();
This function is required to produce assembly for the target machine.
Related
I have C++ program that uses boost (Logger mainly). This programs compiles and runs well on Windows and Ubuntu. However, when I try to port it to Linux Yocto on an embedded system (Intel Atom processor), I got illegal instructions error at runtime.
The program itself is built on Ubuntu PC with Intel-i5.
I debugged the issue and it was some AVX instructions from another library (OpenCV). I disabled all AVX and the problem solved but another problem occurred.
It now tells me that (after reading the core dumb using gdb):
Program terminated with signal SIGILL, Illegal instruction.
0x00007fe1aed03ade in boost::gregorian::date::date(boost::gregorian::greg_year,
boost::gregorian::greg_month, boost::gregorian::greg_day) ()
I did not use boost::gregorian::date explicitly
Is it possible that boost::gregorian::date use some optimized insruction?! like SSE or AVX? (seems non-logical)
Any clue about the issue?
P.S. the error occurs at run-time before anything else. Even a cout at the first line of the main function is not executed before I got the error. So, I suspect some static constructor inside boost causes the problem since there is no static constructor at my code.
Edit:
All librires and the program itself are compiled with -march=bonnell -mno-avx -O2
I'm trying to run the example "Scale_Space_Surface_Reconstruction_3" from CGAL library on CodeBlocks IDE on Ubuntu platform, as it would be nice
to have the IDE support for code completion and a more automatic configuration process.
I managed to successfully execute it by compiling it with cmake on the terminal window.
However, on CodeBlocks, after creating a new project and copying the code from the example, I get the following error:
/usr/local/include/CGAL/Scale_Space_Reconstruction_3/Scale_Space_Surface_Reconstruction_Impl_3.h:165:23: error: variable or field 'pca' declared void
Approximation pca( _nn[i]);
By looking inside the code, I found out that this is due to an undefined Macro CGAL_EIGEN3_ENABLED. As my experiment shows, if I define the macro at
pre-processing time, I do not get the same error. That is because, by defining the macro, the type definition Default::Get< wA,void>::type, becomes
Default::Get< wA, Weighted_PCA_approximation_3<Gt>>::type, and the compiler does not complain any more.
Unfortunately, as a deserved prize for messing with things I do not really understand, I get a segmentation fault at runtime.
How should I change the compiler options of codeBlocks to make the compilation succeed, and the executable run successfully?
I have the following include paths:
/usr/local/lib/CGAL/ /usr/local/include /usr/include /usr/include/eigen3.
I also included the following libraries:
libCGAL.so, libCGAL_Core.so, libCGAL_ImageIO.so, libgmp.so, libmpfr.so, libtbb.so, libtbbmalloc.so, libtbbmalloc_proxy.so
I am working on implementing a user level thread library in C++ using setcontext(), makecontext(), getcontext(), and swapcontext() on a Linux system.
I am using a wrapper function to wrap the function the user wants to run as a thread. For example, the user calls newthread(funcPtr), and within the thread library funcPtr is passed to a wrapper function that runs it.
The error occurs differently depending on whether or not I initiate an unused string within the function. If I include the line string s = "a"; the program will run to completion, but gdb reveals that context is switching to somewhere within the string library. Without this line, the program segfaults after leaving the function wrapper.
The gdb output shows the corruption of the parameters to function().
I ran valgrind but did not see anything particularly out of the ordinary in the output, just many "Invalid read of size 4" and "Invalid write of size 4" warnings, usually within the C++ standard map.
You could try also AddressSanitizer for debugging. It can detect stack buffer overflows. Here's how to use it on Linux:
At least gcc 4.8 is needed for AddressSanitizer and libasan must be installed (e.g. on Fedora yum install libasan as root). Compile and link with -g -fsanitize=address and run the generated executable. AddressSanitizer stops and emits information if it detects the first error, no long log files have to be analyzed. Solve the reported problem, compile and run again until AddressSanitizer doesn't stop the program anymore. Unfortunately there might be false positives because you use swapcontext in your program, but it's worth a try. Instrumentation can be turned off for a specific function by adding the attribute no_sanitize_address: extern int func(void) __attribute__((no_sanitize_address));
Working on a C++ based application, it takes user input and generates a C++ function and compile it to create a .so file and links the function to the main application. Currently had to call an external command "g++" to do it. Wonder if it's possible to call some kind of function, say, "compile" which takes as input an code snippet and produces an .so. More precisely, I need a function that has the following syntax:
sizeOfObjBuf = compile(codeBuf, objBuf);
First parameter is a null terminated string containing a code snippet, the second parameter is the output buffer that hold the compiled code and it returns the size of size of compiled code.
The whole idea is to get rid of dependency on an external program (g++) so the application can run on any Linux system (even when it doesn't have g++ installed).
Thanks.
I'm afraid the answer is "no".
You could implement that function by executing G++ (or some other compiler) in a separate process and waiting for it to finish, but that still requires the user to have a compiler installed.
You can't compile C++ code without a C++ compiler.
I am not going to do the research to figure out how it is done, but I believe the LLVM C++ compiler can be used in this way. All of the parts of LLVM are designed to run as a library, in theory.
OK, a tiny bit of research and I found this: http://clang.llvm.org/docs/LibTooling.html
I recently started using CodeBlocks and began encountering odd runtime errors which I have traced back to printing strings using cout <<. For example, even the following..
#include <string>
#include <iostream>
int main()
{
std::string str;
str = "Hi!";
std::cout << str << std::endl;
return 0;
}
results in an error. It will compile fine (using Borland) but when I run it I get a pop up window saying 'test.exe has stopped working' and in the console I get the message:
Process returned -1073741819 (0xC0000005) execution time : 1.526 s
Press any key to continue.
It compiles and runs fine in MS Visual C++ and with G++ in Ubuntu.. any thoughts would be greatly appreciated!
Cheers,
Weatherwax
My one-off comment ended up helping solve the problem so here it is packaged up as an answer for future users:
This guy had a similar issue and it ended up being a linker issue which he
fixed. The fix is the last post in the thread, although reading the
whole thread could be useful for you.
Long Story short: Borland compiler is a bit dated and annoying to use. Ended up being a linker issue within borland. Better off using a different compiler like GCC/G++ or Visual Studio compiler.
This answer is here to elaborate on the root cause of the issue.
The reason for your crashing program is because the wrong runtime library is being linked. Specifically, your example is compiled as a single threaded object file(the default) but the linking step is using the multithreaded cw32mt.lib runtime -- the "mt" suffix at the end means multithreaded.
The solution is to make sure the runtime your program is compiled to use matches with the runtime you're linking against. A few ways to do this.
Important bcc32 compile switches:
-tW Windows GUI program. WinMain() is expected
-tWC Windows Console program. main() is expected. default.
-tWR Use dynamically linked runtime. Absence implies static runtime linkage.
-tWM Use multithreaded runtime. Absence implies single thread.
Compiling your example program as single threaded like this works:
bcc32 -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32.lib import32.lib,,
or you can compile it as multithreaded like this(note the -tWM switch matching up with cw32mt.lib):
bcc32 -tWM -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32mt.lib import32.lib,,
A third approach that is easier and less error prone is to not call the linker yourself. Instead, let the compiler drive the linker indirectly(similar to gcc):
bcc32 -tWM -oexample.obj -c example.cpp
bcc32 -tWM example.obj -eexample.exe
For your simple example, it can even be shortened to:
bcc32 -eexample.exe example.cpp
Lastly, you can pass the -tW switch multiple times. For example, this command compiles your example as a console program with multithread support and dynamic runtime linkage:
bcc32 -tWM -tWR -tWC -eexample.exe example.cpp
The produced example.exe executable is much smaller and its import table has an entry for CC3250MT.DLL confirming that the borland runtime is dynamically linked.
We should not assume that a non-functioning program is caused by nonconformity to the standard or a bug in the tool we're using without first investigating user error as a potential cause (even though in this case it's tempting to do so). In the OP's case, the code::block IDE didn't have the right commands setup for the toolchain being used.