lldb

I'm trying to use LLDB (because I apparently can't use gdb anymore) to debug som of my code and each time I try to... (lldb) breakpoint set -f file.c -l 65 I get... Breakpoint 1: no locations (pending) WARNING: Unable to resolve breakpoint to any actual locations. I've tried different things like assigning the breakpoint to a function and such but I always get the same error. When running there's no break. Please help! lldb: resolving breakpoints to locations If your out file doesn't have debugging symbols enabled for Code Generation Options then breakpoints likely can't be resolved to

I have seen a lot of answers for this question: error: failed to attach to process ID as switch to GDB . But no one addresses the reason of why it happens? Attaching works fine with the GDB debugger but the default and recommended project setting is LLDB. Can anybody explain why LLDB fails? Is it a common bug or am I doing something wrong? Alternatively, how can I set GDB as my default debugger without changing it manually when creating the new projects? System Info: OS: Lion RAM: 5GB XCode: Version 4.6 (4H127) Device: Mac mini My localhost setting: Make sure you have localhost mapped to 127.0

I'm trying to debug an android native app from Android Studio's native debugging using lldb. My native app contains one libmain.so that is compiled and run by Android Studio and another external libother.so compiled by me. when debugging, I am able to set breakpoints in libmain.so but not libother.so. Both shared objects are stripped but somehow Android Studio makes lldb know about the unstripped version of libmain.so. I want to do the same for libother.so. What command do I need to give lldb so that it would load the symbols from an unstripped file on my local machine? When I do image list I

Is there any way to watch a variable in Xcode using LLDB ? Or is this only possible with GDB ? I'm trying to use the command watchpoint set variable but I get the message: invalid command 'watchpoint set' Watchpoints are supported for iOS and Mac OS X debugging as of Xcode 4.5. To set a breakpoint on a variable named foo , do (lldb) watchpoint set variable foo you can always use the shortest unambiguous name for commands in the lldb console so (lldb) w s v foo would also work here. In Xcode, in the locals window you can right-click/control-click on variables and you'll have an option to set a

I've a framework with a dylib in my iOS app which was compiled on another machine. I checked out the sources on my machine and tried instructing lldb to map the source code path using: settings set target.source-map /source/code/path/in/dylib/prefix /source/code/path/on/my/machine/prefix To no avail, still seeing assembly. Note #1: the dylib was compiled from C++ code in the same version of Xcode. Note #2: I'm used nm -pa /path/to/dylib to determine whether file paths are embedded into the debug info, and they are, lldb doesn't play along for some reason. Thanks UPDATE I've followed Jim Ingham

Is there a way to do remote debugging in Xcode 4? The previous answers to this question were for Xcode 3 and Apple removed the specific debugging in Xcode guide that (I assume) covered remote debugging. For kicks I've been doing this with lldb , but if there's a way with gdb that'd be great. So far, I've been able to start a debug server on the remote machine like so /usr/bin/ssh -l ${REMOTE_USER} -f ${REMOTE_HOST} "/Developer/usr/bin/debugserver localhost:12345" And I can then manually log in with lldb from the Terminal and debug away. What I'd like to be able to do is at the very least start

My process starts child processes and I want to debug these as well, using LLDB on OS X. I can't find any option in the debugger to auto-attach. How to do it? Google is really silent on this issue, but I found a workaround. Run your main process and stop it before it spins off any children. Then put a breakpoint on the function fork : b fork and let the program continue. When it is about to launch a child process, the breakpoint will be hit. At this moment, run another instance of LLDB and let it wait and autoattach to your process: attach -w -n yourapp Now let the parent program continue.