I am trying to generate PTX code for 'nbody' sample program's kernel (nbody_kernel.cu) using clang/LLVM version 3.2. The nbody CUDA program is available in Nvidia's SDK.
I am referring to https://github.com/jholewinski/llvm-ptx-samples project.
Following are my commands,
clang++ -O4 -S -I/usr/local/cuda/include -emit-llvm -target nvptx64 nbody_kernel.cu -o nbody_kernel.ll
opt -O3 -loop-unroll -unroll-allow-partial nbody_kernel.ll -o nbody_kernel.ll
llc nbody_kernel.ll -o nbody_kernel.ptx
After execution of the last command(llc) I get a UNREACHABLE executed! error with the following stack trace
UNREACHABLE executed!
0 libLLVM-3.2svn.so 0x00000033eb79fadf
1 libLLVM-3.2svn.so 0x00000033eb7a01d6
2 libpthread.so.0 0x0000003825a0f500
3 libc.so.6 0x0000003824e328a5 gsignal + 53
4 libc.so.6 0x0000003824e34085 abort + 373
5 libLLVM-3.2svn.so 0x00000033eb788320 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 336
6 libLLVM-3.2svn.so 0x00000033eb43dc37
7 libLLVM-3.2svn.so 0x00000033eb4411a0
8 libLLVM-3.2svn.so 0x00000033eb4422a5
9 libLLVM-3.2svn.so 0x00000033eb210d76 llvm::FPPassManager::doInitialization(llvm::Module&) + 54
10 libLLVM-3.2svn.so 0x00000033eb217ec7 llvm::FPPassManager::runOnModule(llvm::Module&) + 23
11 libLLVM-3.2svn.so 0x00000033eb217ac5 llvm::MPPassManager::runOnModule(llvm::Module&) + 389
12 libLLVM-3.2svn.so 0x00000033eb217c1b llvm::PassManagerImpl::run(llvm::Module&) + 107
13 llc 0x000000000040d157 main + 5415
14 libc.so.6 0x0000003824e1ecdd __libc_start_main + 253
15 llc 0x0000000000409a29
Stack dump:
0. Program arguments: llc nbody_kernel.ll -o nbody_kernel.ptx
1. Running pass 'Function Pass Manager' on module 'nbody_kernel.ll'.
Aborted (core dumped)
I replaced the global indexes like for e.g threadIdx.x with __builtin_ptx_read_tid_x() and others.
There are no problems in generating LLVM IR (i.e .ll). The error pops up while trying to generate PTX from the IR using llc.
Any pointers on what might be going on here ?
Related
I have a problem with the IOS part of my ReactNative App. The Android part works fine. When I create an development build (eas build --profile development --platform ios) there is no problem. But the preview and production builds crash directly after opening the App. The EAS build pipelines have no problems except for one message
fatal error: module 'React' in AST file '/Users/expo/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1XDLP1ZNNJOAB/React-ISQBUSD1JGEA.pcm' (imported by AST file '/Users/expo/Library/Developer/Xcode/DerivedData/MY_APP_NAME-hkvdfgprzzhwypayqwweanuiqofc/Build/Intermediates.noindex/ArchiveIntermediates/MY_APP_NAME/PrecompiledHeaders/MY_APP_NAME-Bridging-Header-swift_3BATV8FO0GBUP-clang_1XDLP1ZNNJOAB.pch') is not defined in any loaded module map file; maybe you need to load '/Users/expo/workingdir/build/ios/Pods/Headers/Public/React-Core/React/React-Core.modulemap'?
I’m not sure if the this is related to my problem because it doesn’t lead to a build failure and the dev Build has the same error message but doesn’t crash.
The App is already published to TestFlight. Therefore, I have the crash reports from the device.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 13
…
Thread 13 name:
Thread 13 Crashed:
0 libsystem_kernel.dylib 0x00000001e5b5a200 __pthread_kill + 8
1 libsystem_pthread.dylib 0x00000001f5d971ac pthread_kill + 268 (pthread.c:1670)
2 libsystem_c.dylib 0x00000001b0951ca0 abort + 180 (abort.c:118)
3 libsystem_c.dylib 0x00000001b09a8890 __assert_rtn + 272 (assert.c:96)
4 MY_APP_NAME 0x000000010487f8d4 facebook::jsc::JSCRuntime::~JSCRuntime() + 136 (JSCRuntime.cpp:393)
5 MY_APP_NAME 0x000000010487f97c ~JSCRuntime + 4 (JSCRuntime.cpp:383)
6 MY_APP_NAME 0x000000010487f97c facebook::jsc::JSCRuntime::~JSCRuntime() + 12 (JSCRuntime.cpp:383)
7 MY_APP_NAME 0x00000001046d88f0 __release_shared + 40 (shared_ptr.h:177)
8 MY_APP_NAME 0x00000001046d88f0 __release_shared + 40 (shared_ptr.h:219)
9 MY_APP_NAME 0x00000001046d88f0 std::__1::shared_ptrfacebook::react::CallInvoker::~shared_ptr() + 64 (shared_ptr.h:959)
10 MY_APP_NAME 0x000000010488cea4 ~shared_ptr + 4 (shared_ptr.h:957)
11 MY_APP_NAME 0x000000010488cea4 facebook::react::JSIExecutor::~JSIExecutor() + 268 (JSIExecutor.h:71)
12 MY_APP_NAME 0x000000010488cd90 ~JSIExecutor + 4 (JSIExecutor.h:71)
13 MY_APP_NAME 0x000000010488cd90 facebook::react::JSIExecutor::~JSIExecutor() + 12 (JSIExecutor.h:71)
14 MY_APP_NAME 0x00000001047c9d64 operator() + 20 (function.h:505)
15 MY_APP_NAME 0x00000001047c9d64 operator() + 20 (function.h:1182)
16 MY_APP_NAME 0x00000001047c9d64 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) + 32 (RCTCxxUtils.mm:74)
17 MY_APP_NAME 0x00000001047d61ec facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) + 24 (RCTMessageThread.mm:69)
18 MY_APP_NAME 0x00000001047d694c operator() + 20 (function.h:505)
19 MY_APP_NAME 0x00000001047d694c operator() + 20 (function.h:1182)
20 MY_APP_NAME 0x00000001047d694c operator() + 24 (RCTMessageThread.mm:61)
21 MY_APP_NAME 0x00000001047d694c __invoke<(lambda at /Users/expo/workingdir/build/node_modules/react-native/React/CxxBridge/RCTMessageThread.mm:60:12) &> + 24 (type_traits:3918)
22 MY_APP_NAME 0x00000001047d694c __call<(lambda at /Users/expo/workingdir/build/node_modules/react-native/React/CxxBridge/RCTMessageThread.mm:60:12) &> + 24 (invoke.h:61)
23 MY_APP_NAME 0x00000001047d694c operator() + 24 (function.h:178)
24 MY_APP_NAME 0x00000001047d694c std::__1::__function::__func<facebook::react::RCTMessageThread::runSync(std::__1::function<void ()>)::$_0, std::__1::allocator<facebook::react::RCTMessageThread::runSync(std::__1::function<void ()>… + 40 (function.h:352)
25 MY_APP_NAME 0x00000001047d5fa0 operator() + 20 (function.h:505)
26 MY_APP_NAME 0x00000001047d5fa0 operator() + 20 (function.h:1182)
27 MY_APP_NAME 0x00000001047d5fa0 invocation function for block in facebook::react::RCTMessageThread::runAsync(std::__1::function<void ()>) + 44 (RCTMessageThread.mm:45)
28 CoreFoundation 0x00000001a94ab924 CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 28 (CFRunLoop.c:1822)
29 CoreFoundation 0x00000001a95140ac __CFRunLoopDoBlocks + 368 (CFRunLoop.c:1864)
30 CoreFoundation 0x00000001a94e4508 __CFRunLoopRun + 2452 (CFRunLoop.c:3218)
31 CoreFoundation 0x00000001a94e91e4 CFRunLoopRunSpecific + 612 (CFRunLoop.c:3390)
32 MY_APP_NAME 0x00000001047bf398 +[RCTCxxBridge runRunLoop] + 264 (RCTCxxBridge.mm:378)
33 Foundation 0x00000001a3912ce8 NSThread__start + 716 (NSThread.m:968)
34 libsystem_pthread.dylib 0x00000001f5d916cc _pthread_start + 148 (pthread.c:893)
35 libsystem_pthread.dylib 0x00000001f5d90ba4 thread_start + 8
…
Expo: 45
Workflow: bare
eas-cli: 2.5.1
During search I tried to replace a lot of code in the AppDelegate.mm I found for this problem. Also from a freshly created and ejected Expo 45 example project.
When replacing almost the entire code from the App.tsx with a simple Text it works.
Furthermore, expo run:ios and npx expo start --no-dev --minify have also no problems.
I hope some of you have an idea how to solve this. I’m stuck on this Issue for some time now. If you need additional information, ask in the comments.
The problem was solved by enabling hermes in the Podfile with :hermes_enabled => true
I'm having a problem archiving my Swift code via Xcode. I keep getting "Error. Illegal Instruction: 4"
Edit: Quick clarification - it builds and runs fine in debug for my device. It will not build for release (archive)
My first error was in one of my dependencies I built via Carthage. Tried to update all dependencies via carthage and they're all doing the same thing - "Error. Illegal Instruction: 4"
Here's the error from one on my dependencies I manually build and add in:
1. Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
0 swift 0x00000001133084ea PrintStackTraceSignalHandler(void*) + 42
1 swift 0x0000000113307cc0 SignalHandler(int) + 352
2 libsystem_platform.dylib 0x00007fff7299e5fd _sigtramp + 29
3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2372278816
4 swift 0x000000010f0507d7 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 9799
5 swift 0x000000010efd1b73 main + 1283
6 libdyld.dylib 0x00007fff727a5cc9 start + 1
error: Illegal instruction: 4 (in target 'libsignal-protocol-swift iOS' from project 'libsignal-protocol-swift')
Here's another one from a different dependency built via carthage:
139 1. Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
140 0 swift 0x00000001070674ea PrintStackTraceSignalHandler(void*) + 42
141 1 swift 0x0000000107066cc0 SignalHandler(int) + 352
142 2 libsystem_platform.dylib 0x00007fff7299e5fd _sigtramp + 29
143 3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2372278816
144 4 swift 0x0000000102daf7d7 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void *, swift::FrontendObserver*) + 9799
145 5 swift 0x0000000102d30b73 main + 1283
146 6 libdyld.dylib 0x00007fff727a5cc9 start + 1
147 error: Illegal instruction: 4 (in target 'DynamicButton' from project 'DynamicButtonExample')
Here's it again from xcode trying to build my code:
1. Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
0 swift 0x000000010aeaf4ea PrintStackTraceSignalHandler(void*) + 42
1 swift 0x000000010aeaecc0 SignalHandler(int) + 352
2 libsystem_platform.dylib 0x00007fff7299e5fd _sigtramp + 29
3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2372278816
4 swift 0x0000000106bf77d7 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 9799
5 swift 0x0000000106b78b73 main + 1283
6 libdyld.dylib 0x00007fff727a5cc9 start + 1
error: Illegal instruction: 4 (in target 'Assistant' from project 'CareApp')
I have absolutely no idea what's going on. I've restarted, cleared DerivedData, cleaned Build Folder, etc.
All the errors are exactly the same whether built via xcode or command line (carthage builds via command line)
I think it's an issue w/ Swift 5.2.4? The last time I successfully archived was 5/26/20. I'm now running Swift 5.2.4 and according to my computer it was created on 5/27/20.
Edit: I have also tried changing the optimization settings for release to "None" - same result.
Try disabling / enabling a whole module optimization or set a Custom Build Setting SWIFT_ENABLE_BATCH_MODE to NO
i follow the tutorial from matt on:
http://jhipster.github.io/video-tutorial/
when i do cloc . i see i have much and much more files i would expect:
$ cloc .
66717 text files.
20401 unique files.
24466 files ignored.
http://cloc.sourceforge.net v 1.60 T=128.46 s (115.7 files/s, 15523.0 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
Javascript 13322 222956 357190 1266221
HTML 676 6984 1047 44885
CSS 76 1883 932 22029
Java 262 3548 1854 15641
XML 53 3383 1395 11307
LESS 79 1388 1546 7269
C/C++ Header 18 1032 300 5109
YAML 190 221 346 3466
CoffeeScript 47 783 699 2467
make 58 417 523 1271
Bourne Shell 31 234 202 1097
Maven 1 12 34 824
Perl 2 87 170 584
DTD 1 179 177 514
SASS 5 42 25 273
C++ 4 43 26 260
IDL 6 38 0 167
Bourne Again Shell 3 28 36 140
D 6 0 0 118
Scala 1 16 7 118
JavaServer Faces 3 3 0 109
Smarty 6 17 30 91
DOS Batch 1 24 2 64
Python 1 7 7 36
XSLT 1 5 0 32
C# 2 3 1 27
ASP.Net 2 5 0 23
C 1 7 4 23
OCaml 1 5 15 6
Lisp 1 0 0 6
PowerShell 1 2 2 4
Lua 1 0 0 2
--------------------------------------------------------------------------------
SUM: 14862 243352 366570 1384183
--------------------------------------------------------------------------------
why is that?
in total it is 610 mb large!
it seems there are a lot of node modules:
$ du -h -d1
584M ./node_modules
24K ./gulp
26M ./src
64K ./.mvn
610M .
is this correct?
and what do i need to add to source control?
thanks
This is normal. Most of those files are NPM dependencies, as you mentioned.
The generated .gitignore should already be configured properly and will ignore node_modules.
I have a crash dump which will not symbolicate normally - when I drag it into the Xcode organizer or manually run symbolicatecrash the system symbols show up, but the application instruction addresses are all untouched.
I tried using atos to work around this problem, but the result I got was:
got symbolicator for myarchive.xcarchive/Products/Applications/MyApp.app/MyApp, base address 4000
___lldb_unnamed_function2115$$MyApp (in MyApp) + 992
___lldb_unnamed_function2096$$MyApp (in MyApp) + 66
___lldb_unnamed_function6053$$MyApp (in MyApp) + 348
___lldb_unnamed_function6064$$MyApp (in MyApp) + 162
___lldb_unnamed_function6002$$MyApp (in MyApp) + 18
___lldb_unnamed_function1029$$MyApp (in MyApp) + 416
___lldb_unnamed_function2280$$MyApp (in MyApp) + 106
___lldb_unnamed_function2272$$MyApp (in MyApp) + 198
___lldb_unnamed_function400$$MyApp (in MyApp) + 96
___lldb_unnamed_function1$$MyApp (in MyApp) + 36
The address currently getting mapped to ___lldb_unnamed_function1$$MyApp (in MyApp) + 36 should correspond to my root invocation in main.m. Obviously, I don't know what the others should be, but I'm guessing that if one is wrong they're all wrong. What could cause this? Does ___lldb_unnamed_function normally appear anywhere other than functions embedded in blocks?
Unfortunately, this will make for a long question, but since it could be an error in calculating the load offset of the app binary I'll list the steps that I followed to yield the above output.
I used dwarfdump -u myarchive.xcarchive/Products/Applications/MyApp.app/MyApp to verify that I am using the correct binary:
UUID: BA41E9A3-4BB5-3F8A-8D57-0D16447FFEC6 (armv7) myarchive.xcarchive/Products/Applications/MyApp.app/MyApp
UUID: A6E0970C-05FE-3A79-887D-84F3892637FD (armv7s) myarchive.xcarchive/Products/Applications/MyApp.app/MyApp
The UUID in the crash dump matches the first one:
Binary Images:
0x97000 - 0x3cefff +MyApp armv7 <ba41e9a34bb53f8a8d570d16447ffec6> /var/mobile/Applications/AF97EC52-7A2F-4772-AA05-74E739BA6882/MyApp.app/MyApp
This line also lists the load offset as 0x97000 and the architecture as armv7. The addresses I'm interested in are:
1 MyApp 0x001357dc 0x97000 + 649180
2 MyApp 0x00134446 0x97000 + 644166
3 MyApp 0x00240cec 0x97000 + 1744108
4 MyApp 0x002416ea 0x97000 + 1746666
5 MyApp 0x0023e2de 0x97000 + 1733342
6 MyApp 0x000de724 0x97000 + 292644
7 MyApp 0x00144f1a 0x97000 + 712474
8 MyApp 0x00144336 0x97000 + 709430
27 MyApp 0x000b1024 0x97000 + 106532
28 MyApp 0x0009d464 0x97000 + 25700
So I ran xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/Products/Applications/MyApp.app/MyApp 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464, which gave me the output above.
Note: since this didn't look correct, I thought perhaps I needed to manually subtract the slide value. I obtained it from the app bundle with xcrun otool -arch armv7 -l myarchive.xcarchive/Products/Applications/MyApp.app/MyApp:
Load command 0
cmd LC_SEGMENT
cmdsize 56
segname __PAGEZERO
vmaddr 0x00000000
vmsize 0x00004000
fileoff 0
filesize 0
maxprot 0x00000000
initprot 0x00000000
nsects 0
flags 0x0
Load command 1
cmd LC_SEGMENT
cmdsize 736
segname __TEXT
vmaddr 0x00004000
vmsize 0x00338000
fileoff 0
filesize 3375104
maxprot 0x00000005
initprot 0x00000005
nsects 10
<snip>
However, rerunning the command with -l 0x93000 gave me a very similar result:
got symbolicator for /Users/arkaaito/Library/Developer/Xcode/Archives/2013-11-07/Zoomingo 11-7-13, 2.14 PM.xcarchive/Products/Applications/Zoomingo.app/Zoomingo, base address 4000
___lldb_unnamed_function2166$$Zoomingo (in Zoomingo) + 684
___lldb_unnamed_function2160$$Zoomingo (in Zoomingo) + 182
___lldb_unnamed_function6165$$Zoomingo (in Zoomingo) + 164
___lldb_unnamed_function6176$$Zoomingo (in Zoomingo) + 46
___lldb_unnamed_function6114$$Zoomingo (in Zoomingo) + 70
___lldb_unnamed_function1129$$Zoomingo (in Zoomingo) + 28
___lldb_unnamed_function2305$$Zoomingo (in Zoomingo) + 2446
___lldb_unnamed_function2302$$Zoomingo (in Zoomingo) + 3714
___lldb_unnamed_function476$$Zoomingo (in Zoomingo) + 512
___lldb_unnamed_function85$$Zoomingo (in Zoomingo) + 532
You have to call atos with the dSYM package, not the app bundle since that normally has the symbols stripped!
So the call is:
xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/dSYMs/MyApp.app.dSYM 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464
I'm using the atos command to symbolicate crash logs.
I have this crash stack :
0 MyApp 0x001c4389 MyApp + 1848201
1 MyApp 0x001c49f1 MyApp + 1849841
2 libsystem_c.dylib 0x33f1f7ed _sigtramp + 48
3 libsystem_c.dylib 0x33f1520f pthread_kill + 54
4 libsystem_c.dylib 0x33f0e29f abort + 94
5 MyApp 0x00021843 MyApp + 133187
6 MyApp 0x00005569 MyApp + 17769
7 MyApp 0x00022b9b MyApp + 138139
8 MyApp 0x0000637b MyApp + 21371
Let's symbolicate the line 6 :
atos -arch armv7 -o MyApp.app/MyApp 0x00005569
=> -[MyAppCoreDataManager persistentStoreCoordinatorForUpdate] (in MyApp) (MyAppCoreDataManager.m:176)
Perfect, but line 5 :
atos -arch armv7 -o Popcarte.app/Popcarte 0x00021843
=> 0x00021843 (in MyApp) + 47
I think it references a #synthesize, but i'm not sure, and I would like to know which one.
Is there a way to know more about this result ?