Where I can find *.debug file with debugging info for CUDA libraries from CUDA SDK, namely CUFFT and CUDA Runtime API (cudart), and how to provide them to debugger and/or profiler?
Without this info debugging application that uses CUDA libraries is very difficult, especially when the error is in CUDA code.
These libraries are not open source, and so naturally debug symbols are not provided.
If you find that there is a bug in a library, I recommend you become a registered CUDA developer and report the issue using the online bug report form. Alternatively (but less preferably), report the issue in more detail here or on the NVIDIA forums.
Before you report a bug, make sure you are confident it is not in your own code first. :)
Related
I found some problem with Visual Studio. My project that use openMP multithreading was twice slow on Visual Studio 2010, than on Dev-C++ , Now I wrote my other project that uses CUDA technology , I think that my project works slow because of Visual Studio, so I need some other compiler that will support CUDA , my questions are:
is Dev-C++ support CUDA?
what compilers support CUDA except Visual Studio?
if there are a lot compilers supporting CUDA what will give best speed for application?
The CUDA Toolkit Release Notes list the supported platforms and compilers.
Well I think it's the other way around. The thing is, there is a driver called nvcc. it generates device code and host code and sends the host code to a compiler. It should be a C compiler and it should be in the executable path. (EDIT: and it should be gcc on Linux and cl on Windows and I think I should ignore mac as the release note did(?))
nvcc Compiler Info reads:
A general purpose C compiler is needed by nvcc in the following
situations:
During non-CUDA phases (except the run phase), because these phases will be forwarded by nvcc to this compiler
During CUDA phases, for several preprocessing stages (see also 0). On Linux platforms, the compiler is assumed to be ‘gcc’, or ‘g++’ for linking. On Windows platforms, the compiler is assumed to be ‘cl’. The
compiler executables are expected to be in the current executable
search path, unless option -compiler-bin-dir is specified, in which
case the value of this option must be the name of the directory in
which these compiler executables reside.
And please don't talk like that about compilers. Your code is in a way that works better with Dev-C++. What is generated is an assembly code. I don't say that they don't make any difference, but maybe 4 to 5%, not 100%.
And absolutely definitely don't blame the compiler for your slow program. It is definitely because of inefficient memory access and incorrect use of different types of memory.
How to debug mingw built binaries to detect heap errors? I see there are several questions on the topic, but they are general and it's hard to find the tool that would work well with MinGW. I spent much time on finding the solution, I hope the combined topic will be helpful.
Such a tool becomes necessary when for example someone reports a bug in your library while running it under Visual Studio debugger, which stops with a "Heap Error".
There is a tool provided by Microsoft called Application Verifier. It is a gui tool that changes system settings to run selected applications in a controlled environment. This makes it possible to crash your program if it causes detectable memory errors. This is a controlled crash that can be debugged.
Fortunately it is obtainable from Microsoft as a separate download. Another way to get it is to have Windows SDK installed with checked Application Verifier checkbox. SDK offers also an option Application Verifier redistributable.
After you configure Application Verifier to have an eye for your app, you need to debug it. Debugging under MinGW is a more common subject, already explained on stackoverflow. [mingw] [debugging] query on stackoverflow gives interesting articles. One of them is How do I use the MinGW gdb debugger to debug a C++ program in Windows?. Gdb is the one I used.
The general questions How to debug heap corruption errors? and Heap corruption detection tool for C++ were helpful to find this tool, but I wasn't sure if it is compatible with MinGW. It is.
What is the difference between GDB & LLDB debuggers? I recently upgraded my Xcode version from 4.2 to 4.3 & started getting warning to upgrade my debugger from GDB to LLDB.
LLDB is part of the LLVM suite of tools that Apple is moving to, including Clang. There are tons of improved features, including improved performance. There's a quick intro for GDB users here: http://lldb.llvm.org/tutorial.html
However...
You might want to take a trip over to the forums at developer.apple.com. There's a fair bit of rumbling about issues with LLDB at the moment (in XCode 4.3.1). One nasty issue, which people from Apple have confirmed, is that viewing ivars while stepping may show you the wrong values.
1. By Difference of Definition
First, What is GDB?
"GDB is the standard debugger for the GNU software system"
The GNU Debugger, usually called just GDB and named gdb as an executable file, is the standard debugger for the GNU operating system. However, its use is not strictly limited to the GNU operating system; it is a portable debugger that runs on many Unix-like systems and works for many programming languages, including Ada, C, C++, Objective-C, Free Pascal, Fortran, Java1 and partially others.2
(quotation from wikipedia)
Second, What is LLDB?
"LLDB is a debugger built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler. LLDB is Apple’s “from the ground up” replacement for GDB, developed in close coordination with the LLVM compilers to bring you state-of-the-art debugging with extensive capabilities in flow control and data inspection. Starting with Xcode 5, all new and preexisting development projects are automatically reconfigured to use LLDB. The standard LLDB installation provides you with an extensive set of commands designed to be compatible with familiar GDB commands. In addition to using the standard configuration, you can easily customize LLDB to suit your needs.
(quotation from Apple official site)
/* I tried to find actual / practical datas to prove the statement : LLDB is already much faster than GDB when debugging large programs.)
However, I could not find it. if there is someone having this related data, please edit this article. */
Both GDB and LLDB are of course excellent debuggers without doubt.
GDB is debugger part of the GNU project created to work along the GNU compiler.
LLDB is debugger part of the LLVM project created to work along LLVM compiler.
2. By Difference of Debugger Command usage
The majority of the commands are the same.
However, lldb and gdb, two different debuggers are developed by different set of developers and thus have a little bit different commands.
This is good link below for comparing difference of these two debugger commands.
let me link the detail below :
https://developer.apple.com/library/content/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-command-examples.html
http://lldb.llvm.org/lldb-gdb.html
This clearly indicates and organizes the difference of commands.
In case the site is not accessible anymore, I summary the major difference of commands below from the linked site.
3. By Personal Opinion
LLDB has been fully integrated from Xcode IDE 5 by default as primary debugger.
From that time, there has been some complaint report about LLDB stability, performance issues and bugs.
However, LLVM with LLDB project has been being incredibly improved and upgraded so far as the one of the core open-source project in the world.
So, I think, at least, LLDB should be used for Apple development environment since LLDB stole the position of GDB and is already primary default debugger at least in Apple world.(In late September, 2016, Xcode 8 integrating LLVM and LLDB was officially released, meaning quite a lot of time has been passed since LLVM/LLDB is default tool-chain for Xcode.)
But, We all already know GDB has been historically and strongly verified and battle-proven debugger over 30 years, which is awesome.
So, I would say…
I would like to use lldb while using clang, use gdb while using gcc compiler as the good combination or pair because lldb is based on llvm, whereas gdb is a GNU debugger.
I wish it could be helpful for you.
Thanks.
I've been browsing the LLVM documentation, and I've got to ask about the availability of back-ends for Windows. Their examples for getting up and running on Windows still use the Visual Studio linker to create the resulting executable files. The JIT example is much cleaner, but I need to create output PE files, not JIT the code in-process.
What I'd like to ask is if there exists an LLVM backend which can perform virtually all of the necessary functions to go from LLVM IR to executable PE file, including handling the importing of Win32 functions from the kernel, and preferably, handling COM types as well.
Sadly not. LLVM itself doesn't handle any of the linking stages, it's just a compiler, so you'll need to integrate it with the Windows SDK linker, or the linker from MinGW.
I am using visual studio 2010, parallel nsight 2.2 and cuda 4.2 for learning. My system is Windows 8 pro x64.
I opened the radix sort project which included by cuda computing SDK in VS, and compiled it with no error. The sort code uses thrust library:
if(keysOnly)
thrust::sort(d_keys.begin(), d_keys.end());
else
thrust::sort_by_key(d_keys.begin(), d_keys.end(), d_values.begin());
I want to know how thrust dispatch the sort function to cuda kernels, so I tried to add breakpoints in front of lines above and compiled the project in debug mode. But when I use parallel nsight for cuda debugging, there are always errors that "no source correspondence for breakpoint".
So, my problems are:
How to debug cuda thrust programs in visual studio with parallel nsight?
Or is there anyone can instruct me using another way to know how cuda thrust dipatch functions to cuda kernels or other functions?
Any advise will be appreciated!
Normally, to debug device code in CUDA, it's necessary to pass the:
-G -g
switches to nvcc. However this modality is not supported with thrust code. You can get an idea of how thrust code gets dispatched to the device by following the structure in the thrust include files. Since thrust is entirely templatized code, there are no libraries to worry about. However that's a challenging proposition. You can also tell the compiler to generate ptx:
-ptx
which is one of the intermediate code types that cuda code gets compiled to. However that is not a trivial thing to parse either. This link gives some alternate ideas for debugging with Thrust.