I'm not sure if I've been dreaming these past years, but all the time I've used lldb, I've been able to autocomplete source file names when setting breakpoints
(lldb) breakpoint set --file m<TAB>
would autocomplete to
(lldb) breakpoint set --file main.cpp
for instance. Now this does not work anymore. Neither in lldb 3.8.0 on Ubuntu 16.04, nor in lldb 10.0.1 or 12.x on macOS.
This renders command-line usage basically impossible if I have to manually copy-paste or type in file names.
What could this be caused by and how do I restore this function?
In one case where it did not work, I had passed -flto compiler flag for Link-Time-Optimization. This removed the ability to autocomplete sources, presumably because info about source files is lost completely.
In another case where I don't have this enabled, there is still no autocompletion.
Too bad lldb cannot simply show the known source files like gdb can with info sources.
Related
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.
How to add source code of some_shared_library.so into gdb.
I've tried to use dir command but it has not helped.
In order for GDB to know what sources match your some_shared_library.so, you must build it with debugging info (usually -g flag).
Once you've done that (and it sounds like you haven't), on many platforms (e.g. Linux) GDB will find the sources automatically. On other platforms, dir is the right command to tell GDB where the sources are.
I'd like to add a file to my project that has a list of gbd commands and load that into GDB within xcode at any breakpoint. Looking at GDB documentation I see the "source" commmand, but it is unknown within xcode's gdb. Has anyone had success doing this?
source -f commandfile.gdb
Thanks,
The source command appears to work although no options are supported if you are really using gdb as the debugger. In the debug console make sure it says "(gdb)" as the prompt. The default debugger now is LLDB instead of GDB. You can change this under Product -> Edit Scheme… and select the "Info" tab at the top. The "Debugger" popup will present you with GDB or LLDB.
I just installed QT 4.6 on snow leopard 10.6.3. I wrote a really simple program. I can generate a xcode project using qmake, but I can't step into QT function. How can I set it up?
By default, qt is built with a debug and a non-debug library. This is my understanding. For example,
% ls /Library/Frameworks/QtCore.framework/
Contents/ Headers# QtCore# QtCore.prl QtCore_debug# QtCore_debug.dSYM/ QtCore_debug.prl Versions/
Also, my default from source build of Qt 4.7 branch also has the *_debug libs.
Setting up for Xcode is cake, you just set up your project and
% qmake -spec macx-xcode
This -spec is the default for the official mac distribution, but if you build your own from source the default is macx-g++ which creates a Makefile project.
This generates a MyProject.xcodeproj that comes preconfigured to link all the necessary Qt frameworks, sets up paths, and has a Release and Debug build target set to the same options as the official SDK's.
This is all assuming you have your qt project file set up, if you need to generate that first from a raw source directory:
% qmake -project
Debugging works "out of the box" for these generated *.xcodeproj files. However, there's one little "hitch". Since Qt is full of custom data types, Xcode doesn't know how to display their "values" in the debugger's summary pane. So you can't see what value a QString has, for example.
There's a method of entering custom macros for display, but I've found these often (always?) don't work for QObjects.
To get that working, I've started a project that uses xcode's debugger c callbacks (also mentioned in the above linked article, though their example doesn't even work o.O). I call it Qt4DataFormatters.
I've just started it and have been adding types as the need arises. It's dirt simple to create one using the existing functions as a template though.
I haven't tried this on Mac, but on Linux you need to take the following process:
First, you need to setup Qt so that it has debugging symbols available to you:
./configure -debug-and-release separate-debug-info # other options
With the debugging symbols available, you should now be able to get valid stack traces.
When building your application with qmake, you need to have the debug (or debug_and_release) flag set in your project file:
CONFIG += debug
Once you've done that, you should only need to tell the debugger where the Qt source is located:
(gdb) dir /path/to/qt/src
After that, list should show you the actual Qt source code. You may need to add additional directories under the src directory for the debugger to pick it all up.
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?