Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'/tmp/testCudaJit-cdc6cf.fatbin': No such file or directory #10

Closed
lxwithgod opened this issue Oct 14, 2019 · 1 comment
Closed

'/tmp/testCudaJit-cdc6cf.fatbin': No such file or directory #10

lxwithgod opened this issue Oct 14, 2019 · 1 comment

Comments

@lxwithgod
Copy link

hi,I use this relase
https://github.com/hfinkel/llvm-project-cxxjit/releases/tag/cxxjit-20190311;
cmake:
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS=ON -DLLVM_USE_SPLIT_DWARF=ON -DCMAKE_INSTALL_PREFIX=/home/xiao.luo/bin/clangJit -DLLVM_ENABLE_PROJECTS="llvm;clang;openmp;libcxx;libcxxabi;lld;complier-rt;clang-tools-extra" ../llvm

clang++ -O0 -std=c++11 -I/usr/local/cuda-10.0/include -L/usr/local/cuda-10.0/lib64 -fjit -lcudart --cuda-gpu-arch=sm_75 ./testCudaJit.cu -o a.out

./a.out 1024*1024

I gett this error:
'/tmp/testCudaJit-cdc6cf.fatbin': No such file or directory

testCudaJit.cu:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include
// Includes CUDA
#include <cuda.h>
#include <cuda_runtime.h>
#include <cuda_runtime_api.h>

template
[[clang::jit]]global void addOne(float* in,int num){

if(supportFor){
for(int tid=threadIdx.x+blockIdx.xblockDim.x;tid<num;tid+=blockDim.xgridDim.x){
in[tid]+=1.0f;
}
}else{
in[threadIdx.x+blockIdx.x*blockDim.x]+=1.0f;
}
}
////////////////////////////////////////////////////////////////////////////////
// Program main
////////////////////////////////////////////////////////////////////////////////
int main(int argc, char **argv)
{
int num = std::atoi(argv[1]);

float * in;
cudaMalloc((void**)&in,sizeof(float)*num);
int blockx=num>1024?1024:num;
int gridx=(num+blockx-1)/blockx>32?32:(num+blockx-1)/blockx;
bool supportFor=gridx*blockx<num;
addOne<supportFor><<<dim3(gridx,1,1),dim3(blockx,1,1)>>>(in,num);

}

@hfinkel
Copy link
Owner

hfinkel commented Dec 29, 2019

I can't compile this example, but if this problem still exists with cxxjit-20191229, please reopen and put all of the code in a codeblock so that it will appear correctly.

error: no member named 'xblockDim' in '__cuda_builtin_blockIdx_t'
error: no member named 'xgridDim' in '__cuda_builtin_blockDim_t'

@hfinkel hfinkel closed this as completed Dec 29, 2019
dutiona pushed a commit to dutiona/llvm-project-cxxjit that referenced this issue Dec 21, 2023
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned
`entry_addr` is valid, it can immediately be returned.

However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function.

In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core:

```
* thread hfinkel#1, name = 'testcase', stop reason = breakpoint 1.1
    frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
   1	int main(int argc, char *argv[])
   2	{
-> 3	    return 0;
   4	}
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).

Thread 1 received signal SIGABRT, Aborted.
thr_kill () at thr_kill.S:3
3	thr_kill.S: No such file or directory.
(gdb) bt
#0  thr_kill () at thr_kill.S:3
hfinkel#1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
hfinkel#2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
hfinkel#3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
hfinkel#4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
hfinkel#5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
hfinkel#6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
hfinkel#7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
hfinkel#8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
hfinkel#9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
hfinkel#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
hfinkel#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
hfinkel#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
hfinkel#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
hfinkel#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
hfinkel#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
hfinkel#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
hfinkel#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
hfinkel#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
hfinkel#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
hfinkel#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
hfinkel#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
hfinkel#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
hfinkel#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
hfinkel#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
hfinkel#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890```

Fix the incorrect error catch by only instantiating an `Error` object if it is necessary.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D86355

(cherry picked from commit 1ce07cd)
dutiona pushed a commit to dutiona/llvm-project-cxxjit that referenced this issue Dec 21, 2023
This patch implemented TTI.IntImmCost() properly.
Each BPF insn has 32bit immediate space, so for any immediate
which can be represented as 32bit signed int, the cost
is technically free. If an int cannot be presented as
a 32bit signed int, a ld_imm64 instruction is needed
and a TCC_Basic is returned.

This change is motivated when we observed that
several bpf selftests failed with latest llvm trunk, e.g.,
  hfinkel#10/16 strobemeta.o:FAIL
  hfinkel#10/17 strobemeta_nounroll1.o:FAIL
  hfinkel#10/18 strobemeta_nounroll2.o:FAIL
  hfinkel#10/19 strobemeta_subprogs.o:FAIL
  #96 snprintf_btf:FAIL

The reason of the failure is due to that
SpeculateAroundPHIsPass did aggressive transformation
which alters control flow for which currently verifer
cannot handle well. In llvm12, SpeculateAroundPHIsPass
is not called.

SpeculateAroundPHIsPass relied on TTI.getIntImmCost()
and TTI.getIntImmCostInst() for profitability
analysis. This patch implemented TTI.getIntImmCost()
properly for BPF backend which also prevented
transformation which caused the above test failures.

Differential Revision: https://reviews.llvm.org/D96448

(cherry picked from commit a260ae7)
dutiona pushed a commit to dutiona/llvm-project-cxxjit that referenced this issue Dec 21, 2023
We experienced some deadlocks when we used multiple threads for logging
using `scan-builds` intercept-build tool when we used multiple threads by
e.g. logging `make -j16`

```
(gdb) bt
#0  0x00007f2bb3aff110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
hfinkel#1  0x00007f2bb3af70a3 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
hfinkel#2  0x00007f2bb3d152e4 in ?? ()
hfinkel#3  0x00007ffcc5f0cc80 in ?? ()
hfinkel#4  0x00007f2bb3d2bf5b in ?? () from /lib64/ld-linux-x86-64.so.2
hfinkel#5  0x00007f2bb3b5da27 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
hfinkel#6  0x00007f2bb3b5dbe0 in exit () from /lib/x86_64-linux-gnu/libc.so.6
hfinkel#7  0x00007f2bb3d144ee in ?? ()
hfinkel#8  0x746e692f706d742f in ?? ()
hfinkel#9  0x692d747065637265 in ?? ()
hfinkel#10 0x2f653631326b3034 in ?? ()
hfinkel#11 0x646d632e35353532 in ?? ()
hfinkel#12 0x0000000000000000 in ?? ()
```

I think the gcc's exit call caused the injected `libear.so` to be unloaded
by the `ld`, which in turn called the `void on_unload() __attribute__((destructor))`.
That tried to acquire an already locked mutex which was left locked in the
`bear_report_call()` call, that probably encountered some error and
returned early when it forgot to unlock the mutex.

All of these are speculation since from the backtrace I could not verify
if frames 2 and 3 are in fact corresponding to the `libear.so` module.
But I think it's a fairly safe bet.

So, hereby I'm releasing the held mutex on *all paths*, even if some failure
happens.

PS: I would use lock_guards, but it's C.

Reviewed-by: NoQ

Differential Revision: https://reviews.llvm.org/D118439

(cherry picked from commit d919d02)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants