lli is generating run-time error for clang++ generated IR while the generated executable is not generating run-time error for c++ source code - c++

I am trying to generate a bit code from a c++ source code and running through the just-in-time compiler. When I compile through the clang++ and generate binary executable it runs perfectly but when I generated the bitcode and tried running through the JIT with lli command it generates run-time error. Could you please help me understanding what's going on.
For example: Let example.cpp contains the following code:
#include <iostream>
int main(){
std::cout << "\nHello World!";
return 0;
}
I am using the following command to generate executable which runs perfectly fine.
clang++ example.cpp
I am using the following command to generate the bitcode:
clang++ -S -emit-llvm example.cpp
And then running through the JIT using the following command which generates run-time error:
lli example.ll
I am getting the following access violation error:
Stack dump:
0. Program arguments: lli example.ll
#0 0x00000000025fd9af llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:0
#1 0x00000000025fda42 PrintStackTraceSignalHandler(void*) /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:0
#2 0x00000000025fb7ca llvm::sys::RunSignalHandlers() /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Signals.cpp:68:0
#3 0x00000000025fd329 SignalHandler(int) /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:0
#4 0x00007fa75dbdc390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
Segmentation fault (core dumped)

Try compiling with clang++ -S -emit-llvm -fno-use-cxa-atexit example.cpp.
I think it's probably because clang and gcc try prefer __cxa_atexit to
atexit by default (these are functions used for cleaning up global objects when a program exits). Meaning you'll get a linker error if your libc implementation doesn't support the former. So disabling the use-cxa-atexit flag should work.

It seems that it's a library linking issue. Try to use the followings:
Try lli -force-interpreter example.ll instead of lli example.ll
When JIT can't work properly, you should try interpreter.
if the following err:
LLVM ERROR: Could not resolve external global address: __dso_handle
Then add -fno-use-cxa-atexit to clang flags, reasons from [LLVMdev] MCJIT/interpreter and iostream.
After retry lli -force-interpreter example.ll if still have some errors like LLVM ERROR: Tried to execute an unknown external function: .... Then you should recompile LLVM with ffi library enabled. See the following for reasons: Advice on Packaging LLVM¶
and [LLVMdev] lli --force-interpreter does not find external function

Related

GDB doesn't work: Cannot insert breakpoint 1. Cannot access memory at address [...]

I'm trying to setup my vscode to debug C++ programs using gdb from WSL. But I faced problem with gdb on my WSL 1 (Ubuntu 22.04 LTS). Whenever I try set a breakpoint and run a program, I get the following error:
Starting program: /mnt/d/Informatics/vscode/test/a.out
warning: opening /proc/PID/mem file for lwp 7674.7674 failed: No such file or directory (2)
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x10e0
The contents of the program don't matter, always getting the error. Code is compiled using the following line:
g++ -Wall -pedantic-errors -O2 -std=c++23 -ggdb3 -fdiagnostics-color=always /mnt/d/Informatics/vscode/test/*.cpp
gdb version: GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
g++ version: 12.0.1 (also tried with 11.2.0 - no difference)
On windows with g++ and gdb from MinGW the problem doesn't exist, so this should mean I'm not using the gdb debugger wrong.
Edit: tried compiling gdb 11.2 from source as suggested in comments, but this did not fix the problem. Only difference is that it's not showing /proc/PID/mem warning now.
Starting program: /mnt/d/Informatics/vscode/test/a.out
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x10e0
Edit 2: Compiled gdb 10.2 from source and it works, the problem does not appear. I don't know why it doesn't work with any version above 10.2. Is it gdb bug or WSL bug?

External functions from standard libraries are unresolved in lli

I am trying to run simple code in llvm lli (according to Getting Started with the LLVM System)
#include <stdio.h>
int main() {
printf("hello world\n");
return 0;
}
I got the .bc file with
clang –O3 –emit-llvm hello.c –c –o hello.bc
and
lli hello.bc
but getting the next error:
LLVM ERROR: Program used external function '_printf' which could not be resolved!
I think it is very basic error, but I didn't understand what I did wrong.
working on windows.

lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Running the following code with clang++ -S -emit-llvm main.cpp && lli main.ll on Linux(Debian)
#include <future>
int main () {
return std::async([]{return 1;}).get();
}
fails to run on lli due to the following error:
LLVM ERROR: Cannot select: 0xd012e0:
i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8** #_ZSt15__once_callable> 0 [TF=10]
0xd020c0: i64 = TargetGlobalTLSAddress<i8** #_ZSt15__once_callable> 0 [TF=10]
In function: _ZSt9call_onceIMNSt13__future_base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
Questions:
What does it mean?
Are there any compiler-flags that fix this problem?
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
EDIT:
The motivation behind this question is to understand the differences between libc++ and libstdc++ that leads to this specific error message (on Linux) in llvm's orcjit.
On OSX gcc has been deprecated and clang uses by default libc++.
To reproduce this error on OSX you probably have to install gcc & use -stdlib=libstdc++.
Here is the llvm-ir (it's unfortunately to big to embed it here directly)
EDIT:
The error turned out to be caused by the lack of TLS support in the JITer. This answer describes another problem concerned with linking and lli.
If you have a look at the generated IR from clang++ -std=c++11 -S -emit-llvm test.cpp, you will find that many of the symbols, e.g. _ZNSt6futureIiE3getEv, are only declared, but never defined. The linker is never called, since -S "Only run[s] preprocess and compilation steps" (clang --help).
lli only executes the IR Module and does no "implicit" linking, how is it supposed to know which libraries to link in?
There are different solutions to this, depending on why you are using lli:
compile and link the IR Module: llc main.cpp && clang++ -lpthread main.s (pthread is required s. What is the correct link options to use std::thread in GCC under linux?)
(unconfirmed) use LD_PRELOAD="x.so y.so" to force-load the libraries before running lli
JIT the module programmatically and use LoadLibraryPermanently(nullptr) (adds symbols of the program into the search space) and LoadLibraryPermanently(file, err) for additional libs (s. http://llvm.org/docs/doxygen/html/classllvm_1_1sys_1_1DynamicLibrary.html)
I can only guess as to why libc++ works for you since it fails on my machine, but presumably it's the case because it is loaded into lli already and lli calls sys::DynamicLibrary::LoadLibraryPermanently(nullptr) to add the program's symbols to its JIT search space (s. https://github.com/llvm-mirror/llvm/blob/release_40/tools/lli/OrcLazyJIT.cpp#L110).
The LLVM-dev mailinglist pointed out:
What does it mean?
The llvm-backend in orcjit does currently not support thread-local storage(TLS)
a minimal example is:
extern thread_local int tls;
int main() {
tls = 42;
return 0;
}
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
this works because libc++ future::get implementation does not use thread_local keyword.
Are there any compiler-flags that fix this problem?
currently there is no solution.
Using lli -relocation-model=pic trades this problem with a relocation failure.

GDB fails to run program due to KERNELBASE.dll error

I've only started getting this problem recently, and I have no idea when it started occuring/what causes it.
I have this simple test program here:
#include <iostream>
int main()
{
return 0;
}
but when I try to run it normally, it creates a stackdump.
Stack trace:
Frame Function Args
00CBC498 6101D93A (00000198, 0000EA60, 000000A4, 00CBC508)
00CBC5C8 610E2F3F (00000000, 60FC04E8, 00CBC658, 7794ABEE)
When I try to run it in GDB, however, it just plain fails to do so.
gdb: unknown target exception 0x406d1388 at 0x778edae8
Program received signal ?, Unknown signal.
0x778edae8 in RaiseException ()
from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
(gdb) n
Single stepping until exit from function RaiseException,
which has no line number information.
[Thread 14880.0x11ac exited with code 1080890248]
[Thread 14880.0x3fd8 exited with code 1080890248]
[Thread 14880.0x3b24 exited with code 1080890248]
[Inferior 1 (process 14880) exited with code 010033211610]
This is how my compiler's set up:
g++ -g -std=c++1y -Wall -c main.cpp -o main.o main.cpp compiled...
g++ -g -std=c++1y -Wall -o a main.o Successfully compiled!
Any idea as to what I'm doing wrong here?
The platform I'm using is Windows, and I'm using Cygwin as my development environment.
OF NOTE: I still get the aforementioned GDB error no matter what I have in main.cpp.
ALSO OF NOTE: Here are the additional files in the a.exe executable:
I formerly needed cygboost_filesystem.dll to get boost_filesystem to work, and I need libgcc_s_sjlj-1.dll and libstdc++6 because it won't work without them.
Update gdb to the 7.11.1-1 experimental release version.
Details of GDB bug

Execute Openmp program in LLVM-3.0

I generated a .ll file using llvm-gcc for a Openmp program(written in c).
Then Optimized using opt(version 3.0)
But when I try to execute the optimized .ll file using lli or llvm-ld, getting the following errors,
LLVM ERROR: Program used external function 'GOMP_parallel_start' which could not be resolved!
Here is the step I followed,
$ llvm-gcc -emit-llvm loop11.c -fopenmp -o loop.ll -S
$ opt -O3 loop.ll -o loop.opt.ll -S
$ lli loop.opt.ll
LLVM ERROR: Program used external function 'GOMP_parallel_start' which could not be resolved!
Please help me to solve this problem.
Thanks in advance.
You have to link / load the OpenMP runtime, libgomp in this case.