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.
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 have a quite large x64 c++ program that is compiled with Visual Studio. There are two ways how do we compile it - one is with sln solution file (from IDE or through msbuild), another is through Makefile in VS command prompt (which then internally uses Visual Studio's cl.exe and link.exe).
Somehow I got into situation that binary build through Makefile produces executable with /AVX instructions enabled, and I don't want that, so I want to find out how to get rid of it.
I try to compile and link it without any parameters (especially without /arch:AVX). I hope that I compile and link the same sources and libs in both sln and Makefile.
What is the easy way how to find out where the AVX comes from? Project includes dozens of h/cpp files, around 40 own libs, 10 windows libs. How would you proceed?
The simple way, find an old PC without AVX, run your app in debugger, it’ll crash with invalid instruction runtime error and will trap to debugger. This way you’ll immediately find out what code compiled into that instruction.
Another, harder way, write a C# console app that disassembles the compiled DLL or EXE, and searches for AVX instruction. You’ll need Gee.External.Capstone nuget package for disassembling, PeNet package for parsing into sections. Also this code to disassemble. The disassembleStreamEx method will return you the stream of the instructions. Search for X86InstructionGroup.AVX or X86InstructionGroup.AVX2 instructions, print addresses, then use e.g. WinDBG + PDB file to translate addresses into source code location.
Update: before doing that, search your codebase for files containing _mm256_, and *.asm files. If you’re lucky you won’t have to do anything else.
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.
In our project, we are building an ELF file and a partially linked file (PLF) which is converted to a proprietary format and loaded into memory after the ELF is loaded. We use Codewarrior to run and debug, which has been working just fine (the C++ source code is always available to step through when debugging).
I've recently made a change where some code and data are compiled into a different section in the PLF file (.init, which was previously empty). Now, when debugging, a majority of the files are available only in assembler. When I re-build, no longer using .init, we can step through C++ source code again.
Does anyone know why this would be the case?
why this would be the case
One reason could be that codewarrior is not expecting to find code in .init section.
You are unlikely to get a good answer here. Try codewarrior support forums.
I got this working by switching the order of the sections using the linker command file (.lcf) so that the .init section comes second after .text. I guess as Employed Russian suggests, CodeWarrior is surprised by having code in .init and craps out. Changing the order of the sections seems to have no ill effects and now debugging works as expected again.