LLVM debugger (lldb) uses a source file for debugging (e.g. for breakpoint). I want to use lldb without having source files, only with intermediate representation files (.ll files).
Is it possible? If not, can I do that with gdb debugger? Is there another idea?
I'm not sure you can debug using the IR, but in the worst case, you can always just debug the bare assembly without symbols of any kind. Having at least function labels is nice, though.
Related
I have an executable that makes use of /usr/lib/libcrypto.0.9.8.dylib. I've (more or less) figured out some breakpoints within that library that I'd like to understand better.
However, I do not remember if this is the stock openssl on the system, or if I later installed it (don't think so, pretty sure that homebrew would have put it elsewhere).
This is for macOS Mojave (10.14). If the debug symbols have been stripped in libcrypto, I'm not sure I even know how to check that (nm?). I have, however, downloaded and extracted the source (matching the version).
Is there any way to configure lldb such that it can show me the source code instead of assembly language? If the debugging symbols have been stripped (without even checking, I'd assume so) can you even do this?
I'm trying to do my own research for this, but I'm not even sure I know what keywords to search with yet.
The tools on Darwin don't store debug information in the binaries, but rather in a separate standalone bundle (a dSYM). So if you don't have a dSYM for your libcrypto then you don't have debug information for it, and there's no way to reconstruct the code->source map.
Some distributions have debug packages as well as release ones that include the dSYM's. lldb matches dSYM to binary using a common UUID computed by the linker. You can print the UUID with the command dwarfdump --uuid <PATH TO BINARY> and then see if wherever you got the library from kept that dSYM.
But if you can't find the dSYM, you aren't going to be able to do any source level debugging.
I compiled my application with debug symbols using clang. When attaching to the application using lldb and stepping into, for example, __cxa_throw, I don't see the source code of libc++abi.dylib. What am I doing wrong?
You do get some debug information for the STL, because a lot of the STL code is in header files that get compiled into your application. But you don't have debug information for the code that is actually compiled into libc++abi.dylib, since Apple doesn't distribute dSYM's for system libraries. __cxa_throw is actually a function in the library.
As a separate issue, because most people don't actually want to step into STL code, lldb has a setting:
(lldb) set show target.process.thread.step-avoid-regexp
target.process.thread.step-avoid-regexp (regex) = ^[^ ]+ std::|^std::
that will cause stepping to artificially step over code from the STL. You can undo this by setting that value to "". That will get you into the inlined code when stepping.
I have the following problem:
I have a Matlab program in form of some set of *.m files. It is later compiled into executable and used. The problem is that occasionally the resulted executable just hangs and this behavior cannot be reproduced when debugging/running *.m files from IDE (even using the same input data).
To figure out what hapens I intended to:
compile (somehow) *.m files into C/C++
compile C/C++ as debug to get .exe and .pdb
And later when .exe hangs just 'attach' visual studio debugger to hanged .exe to check where it 'loops/waits'.
Unfortunaley Matlab Compiler (as I was told today) does not produce C/C++ code before creating executable. I was misleaded by -g option of mcc which according to the documenttion is supposed to do the following:
-g Generate Debugging Information
Include debugging symbol information for the C/C++ code generated by MATLAB Compiler.
It looks exacly like the thing I want to archive.
I would appreciate if someone could explain me that discapency or suggest how to archive what I am trying to do (if it can be done at all).
It is not possible to create a debuggable code in Matlab compiler, because the deployed code uses MCR. (Matlab virtual machine) .
See this question : Is there any way to debug compiled components using Matlab Debugger?
Since you don't have errors, but rather an infinite loop, the best solution in that case would be screen outputs, and hopefully you will trace the bug.
I'm working on a project, and on a machine without Xcode, I'm getting a crash. (of course it works on my machine B-/) I have a crash log, with a PC offset for the crash. I'd like to be able to see where that actually is in the code. I know that Code Warrior can disassemble the code (presumably, only debugable code) and show it interspersed with the C code, then I just have to look for that address, and I'm done.
Is there an easy way to do this in Xcode?
thanks.
There are two things in Xcode you may want to look at. The first would be to select your source code file and choose Build->Show Assembly Code. What this won't give you though is offsets.
The second assembly capability is in the debugger. Choose Run->Debugger Display->Source and Disassembly, and the debugger will show you both source and assembly code side-by-side. However, the two are not interspersed.
If neither of these Xcode facilities give you what you need, your only recourse may be the otool command line tool.
I've never found a way to generate or view source and assembly interspersed.
I wrote an LLVM transformation that basically replaces mallocs by kind of guarded mallocs and some other stuff.
I'm using clang (or llvm-gcc) for compiling a c file to get a bitcode file (using the -emit-llvm option) which contains debug information. These also contain method names, line numbers and so on.
Afterwards I'm using opt to instrument this bitcode file. The result is an instrumented bitcode file, still containing all relevant debug infos.
In a third and last step, since we need some runtime libs, we link the bitcode against some other bitcode files using llvm-gcc to get a final binary.
This binary I cannot debug since it doesn't contain any debug information although all linked bitcode files did contain them. The only thing gdb can tell me is in which function we are but no line numbers and so on...
I would be grateful for any hints.
As I understood you are running optimizations (opt tool optimizes the code and debug information also). So may be the missing part which you want to see when debugging is a result of optimized debug information ?
P.S.
I would add this in the comment, but unfortunately I don't have 50 reputations which are needed to add a comment.