I have a XCode which builds and runs under XCode.
I would like to know if it is possible to debug it using a gdb I build under Mac OSX (gdb 7 to be specified). If yes, can you please tell me how can I do that?
Thank you.
gdb-7.0 reverse debugging currently can only work with two classes of targets:
1) a remote simulator/emulator/virtual-machine that supports going backwards, or
2) the built in "process record" target, which at present has only been ported to x86-linux, x86-64 linux, and moxie linux.
Well, now -- I take that back. I recently discovered that process record can work with any remote x86 target, so if you're connecting with your macintosh target via "target remote", you might just be able to do it!
There is an online tutorial for process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial
More info about process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord
And about gdb reverse debugging here:
http://www.sourceware.org/gdb/wiki/ReverseDebug
So you want to use your own version of gdb to debug your executable? Easy!
Open Terminal, and do something like this:
$ cd <directory where Xcode project lives>
$ cd build/Debug (for example - depends on project configuration)
$ /usr/local/bin/my-gdb ./MyExecutable
Of course, specifying the actual path to your custom gdb version.
XCode's debugger is gdb (likely with Apple-specific modifications.) When you debug an application you can get to the gdb command line by opening the Console from the Run menu.
What requirements are imposed on your application that would require you to debug with your own version of gdb?
Related
here is a link to a C++ (CLion) project. I've distilled/simplified the issue down as much as I could.
The problem is that when debugging, LLDB (version 3.9.0) crashes.
Steps to reproduce crash:
Open project with CLion 2017.1 (use built in LLDB for debug)
Compile the Project
Place breakpoint in main.cpp line 14
Run in debug mode.
Once you're at line 14 breakpoint, then output the variable "an_integer" via the "print an_integer" command.
Crash
The Error/Crash Report:
Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file
/Applications/buildAgent/work/92515a49514b3993/lldb/llvm/tools/clang/lib/AST/Decl.cpp,
line 1360.
Note that this crash occurs with LLDB v3.9.0 on Mac v10.12.4. But it does not occur with LLDB 3.7.0 on Mac 10.12.4.
Ultimately, I'm wanting to know if I'm doing something dumb in my project code? If not, is this a bug with CLion or LLDB? Is there somewhere that I should post this to help get the bug (if it is that) resolved?
That doesn't look like your bug. For some reason lldb is having trouble ingesting the type information produced by the compiler.
I don't have clion so I can't try that, but if I just build your test project, either with a PCH or without, using clang from Xcode 8.3 I don't see this crash. Best thing to do is to build this project with CLion, then make a dSYM (if CLion doesn't do this for you.) You do that by running:
> dsymutil TestingLLDBBreaking
Check that you can reproduce the crash with the dSYM, and if so then file a bug with http://bugreporter.apple.com with the executable and the .dSYM.
So I had the same problem for a while.
just before almost formatting my mac I've re-cloned the project to a different directory and ran it from there. No issues. (i'm sure its a mac-os thing).
Good luck :)
Recently I found that it's possible to debug via lldb remotely but from command line. So the question: is it possible somehow to replace standard lldb with my version or to have any control over command line which is passed from xcode when it's launched.
there are two reason for doing this:
pure remote debugging, extremely convenient when debugging focus/eventTarget issues (window/process activation/deactivation)
debugging of root processes following the manual Debugging in XCode as root . I'm aware about "debug as root" in xcode 6 option, but it doesn't work for me for some reason... Also notice that there an option to select a debugger in lld Debugger/Attach to Process/By Process Identifier (PID) or Name... However the option is only.
I used homebrew installed gdb, and created code sign for it. It seems I have installed it completed. But when I use gdb command to debug the app in /Applicaions, it always prompted me no such file or directory, I have no idea about it. My system is 10.9.4, and GDB version is 7.7.1.
Wait for your help!
GDB does not automatically load application bundle directories. You need to give it the path to the main Mach-O executable. Something like /Applications/Reveal.app/Contents/MacOS/....
I don't know what the main executable for Reveal.app is named, but if it is named Reveal your command would look like this.
gdb /Applications/Reveal.app/Contents/MacOS/Reveal
XCode comes with LLDB, presumably there is a way to enable it as the debugger to use when debugging XCode projects.
Of course being a Linux user I have become a hardcore command-line fanatic and I have a well-established Vim and Tmux workflow. Also being a code portability freak, 100% of my scripts work on both OS X and Linux.
So is there some sort of way to "Pull out" the LLDB from deep within the bowels of XCode and run it from the command line? What are the benefits of compiling it ourselves, as directed from the instructions?
I am guessing that the usual reasons to build from source apply here as well: We can get the latest bleeding edge features and bugfixes by rebuilding it. It's just better. etc. How can I check which version of clang a particular LLDB instance uses? I did compile it using the XCode project (by following those directions), and version reports:
steven#new-host-3:~/Library/Developer/Xcode/DerivedData/lldb-bvjmzslapfdmdmabqocfcogrlbfc/Build/Products/Debug Wed 3 20:37 10137
% ./lldb
(lldb) version
lldb-300.99.0
The answer won't directly help me since I already know how to build the entire thing from source, but for everyone else out there with a Mac who is thinking about ditching GDB (and actually intends to do debugging out of a command line), maybe there's a shortcut (that I skipped)!
I guess there still is a significant difference between this bleeding edge svn-sourced manually compiled LLDB and the LLDB that Apple packages with XCode and XCode CLT.
The convention on Mac OS X with Xcode 4.6 is that you either install the CommandLineTools package (which installs things in /usr/bin etc) or you prefix commands with xcrun. xcrun lldb, xcrun clang, etc. Most users of Xcode do not use command line tools so this arrangement works well. I believe you can download the CommandLineTools package alone if you're only doing command line development from http://developer.apple.com/ (I think an Apple ID is required to get access -- I think a free account will be sufficient to get the CommandLineTools package) which means you can get the full command line tools with a single 128MB download.
The change to have the canonical home for everything be in /Applications/Xcode.app is a relatively new one and the goal that drove this change was to make the developer tools relocatable. It will install in /Applications/Xcode.app if you download it from the Mac App Store, but it doesn't need to be there. You can install multiple versions of the tools on a single system - for instance, people who have access to the Xcode 5 Developer Previews will see that it installs in a separate location so the Xcode 4.6 tools are still present on the system. The xcode-select command line program can be used to specify which set of Xcode.app tools should be invoked by xcrun clang etc.
As an aside, a useful shortcut for people more comfortable building from Terminal: if you are building lldb you can do xcodebuild -configuration Debug and it will build the Debug configuration for you, no Xcode UI required.
Maybe I took the scenic route here.
% /Applications/Xcode.app/Contents/Developer/usr/bin/lldb
(lldb) version
LLDB-179.6
(lldb)
This is probably useful enough to get work done with.
It's kind of unfortunate to see that the Xcode CLT and Xcode itself come with similar tools, it's a waste of disk space.
See the sister question here.
I need to step through the Qt code to help solve a bug in my C++ application. I've downloaded qt-mac-opensource-src-4.5.2.tar from here and followed the install instructions that came with this:
unpacked the file to /tmp.
typed ./configure -debug.
typed make.
typed sudo make install.
edited the PATH environment variable as instructed.
set the DYLD_IMAGE_SUFFIX environment variable to _debug.
This installed Qt and my Qt application runs, but I still can't step into the Qt code.
I'm using Xcode 3.1.3 and tried changing the Executable Info to "use debug suffix when loading frameworks". This generated a lot of warnings like:
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qmalloc.o" - no debug information available for "global/qmalloc.cpp".
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qnumeric.o" - no debug information available for "global/qnumeric.cpp".
and also a lot of non-qt related warnings.
I'd shutdown the Macbook Pro overnight, which I can only assume clears the tmp directory as the unpacked file is no longer there.
I think I could fix it by rebuilding Qt without frameworks, but this is more of a work-around than a fix that will probably come back to bite me. I'm also a bit reluctant to do this, when each rebuild takes between 3 and 4 hours.
Alternatively, would downloading the binaries and debug libs work?
I'd be grateful for any suggestions on what I'm missing and how I address this.
Thanks.
With the help of Qt support, I've now resolved this.
There were a couple of issues:
The Qt debug "make install" doesn't currently generate dSYM files for the _debug stuff. They've raised a bug about this. To get round this:
4a. cd /usr/local/Trolltech/Qt-4.5.2/lib
4b. Type /usr/bin/dsymutil -o QtGui.framework/QtGui_debug.dSYM QtGui.framework/Versions/4/QtGui_debug
4c. Repeat for each Qt framework.
The tmp directory does indeed get wiped on each reboot. To get round this:
7- Copy the entire contents of /tmp/qt-mac-opensource-src-4.5.2 to a new directory ~/Qt .
I also added both the frameworks and source code to the Xcode project.
Have a look at this http://doc.trolltech.com/4.5/debug.html
There is a section especially for debugging under MacOSX and Xcode...
I guess you need to generate a makefile with debug option using qmake !
In OS X 10.6 and 10.6.1, setting DYLD_IMAGE_SUFFIX to _debug will cause problems. Hopefully this will be addressed by a future update of OS X 10.6.