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.
Related
I know that you can make clang output LLVM IR using -emit-llvm option, however this makes it the sole output.
I was wondering if there is some combination of compiler options that would make clang function exactly as before, but also produce .ll files as a byproduct?
The problem I'm facing right now is a project with a very complicated cmake-based build, for which I can only change clang compile options. I want to generate llvm IR files for it, but unfortunately, if I just pass -emit-llvm, CMake fails, since it's compiler tests/sanity checks don't pass (since .ll file is generated instead of the valid executable).
Is there some way to make clang generate both exe/object and .ll files? Or somehow workaround this issue in other ways?
There are at least two ways to achieve that:
-flto: instead of each object file you will get an LLVM Bitcode file (except of files that compiled from assembly, they will still be object files).
-fembed-bitcode: clang will add another section into the final executable, which contains all the LLVM bitcode files (again, except of the assembly files, they will still be object files). Then, you can use LibEBC to extract all those files.
No matter which approach you take, you would have to use llvm-dis tool to convert LLVM Bitcode files into LLVM IR files.
I hope it helps.
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.
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.
Is it possible to symbolicate MonoTouch crash dumps and get line numbers out of them? If so, how is it done?
I have configured my project in the following way:
Build in release mode
Checked 'Enable debugging' in Project Options -> Build -> iPhone Build -> General tab
Checked 'Emit debugging information' in Project Options -> Build -> Compiler
Now, when I run symbolicatecrash against a dump, I get my method names in the stack trace but with only an offset against them (eg '+ 268') rather than a line number.
I am using MonoTouch 4.21.
Short answer: I think the issue is with the ahead-of-time (AOT) compiler - but you better email such question to the mono-devel mailing-list to get a definitive answer.
Long answer:
Mono compilers/runtime (and that behavior is inherited by MonoTouch) keeps the debugging information, that includes line numbers, for its assemblies inside mdb files.
XCode works with DWARF (DSYM) files. When XCode symbolicate a crash dump it looks (only) in the (AOT-produced) DWARF symbols to get its information - i.e. the mdb files are not looked up.
Now the Mono debugger (and runtime) can cope with DWARF too (which should fit the bill). However for MonoTouch I'm not sure the AOT compiler (which calls gcc) is producing the final DWARF symbols containing the C# line numbers - resulting in symbols and offsets (both available to gcc) only being available.
which version of xcode are you using?
There was an problem in earlier versions -
check https://github.com/chrispix/symbolicatecrash-fix
I have a program that I intend to distribute to end users, and would like to have receive crash reports from them. If I were using MSVC, I would generate minidumps and have those sent to me, and then inspect them with the corresponding PDB to get a useful stack trace, at the very least.
What is the equivalent of doing this with GCC? I can generate a stack trace, but if I want this to be useful, it requires having debug symbols compiled into the executable (with -g). Obviously this is unacceptable for release distribution, since the executable can balloon in size quite a bit.
I googled a bit and found references to objcopy being able to separate out debug symbols to a separate file, but that page implied I would still need to have the debug symbols available alongside the release executable, which again is obviously unacceptable.
Well the idea is that you compile with -g to add debug symbols but not slow the program down, ie. most programs will do -g -O2 then you can seperate debug symbols with objdump. After that you can strip your release build so it won't have any debug symbols.
Update: Recent gdb supports separate debug files, see https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
For example you can doo
objcopy --only-keep-debug prog prog.debug
strip prog
Now your prog won't have any debug symbols. But you can use proc.debug file to debug it in gdb.
I couldn't find an exact answer to this, but I found an alternate solution that works just as well: Compile with optimization and other release flags alongside -g, store the resulting executable somewhere, then remove debug symbols using strip. Ship the stripped executable, and when you get a stack trace, use addr2line in combination with the original, unstripped executable, and you should get all the symbols back.