Re: The case of the broken breakpoints
Re: The case of the broken breakpoints
- Subject: Re: The case of the broken breakpoints
- From: Oftenwrong Soong <email@hidden>
- Date: Sat, 2 Jan 2010 16:21:19 -0800 (PST)
Hi all,
First, many thanks to Jason Molenda for the very helpful explanation of how Xcode interfaces with gdb. That filled in quite a few holes in my knowledge of how debugging works.
Somehow, I must have managed to confuse Xcode in the manner Jason described:
On Thu, December 31, 2009 4:34:01 PM, Jason Molenda <email@hidden> wrote:
> The optimization falls down in two main cases: Symbolic (function name)
> breakpoints and when the Xcode session doesn't know what executable a
> source file maps to. With symbolic breakpoints, Xcode doesn't know what
> dylib this might be in - if you do Run > Show > Breakpoints you'll see a
> "Location" entry where you can add a dylib/framework/etc name but Xcode
> doesn't know how to fill that in itself. In the latter case, a common issue is
> a source file that is compiled into a static archive (aka ranlib archive aka .a
> file) and then linked into one or more binaries. Xcode can have trouble
> tracing the source file through to its final destination bundles/dylibs/etc. The
> basic issue is that Xcode can't match a source file to a single installed
> binary -- there are many interesting ways people come up with to confuse
> Xcode in this manner. :)
I was in an intense hack/compile/debug/hack cycle when suddenly, the breakpoints turned yellow/orange/whatever. What's notable about my experience was that I tried to place breakpoints in the main() function (this was a C++ Tool project with default project settings).
Since this has happened to me several times in the past, then is there a way, once it happens, to "un-confuse" Xcode? Assuming I leave "load symbols lazily" turned on, is there a way I can explicitly tell gdb which executable the main.cpp file maps to?
Alternately, is there a way I can "reset" the confusion? After the confusion started, I resorted to deleting the project files and creating a new project. For that reason I think whatever causes the confusion gets stored or cached in those files. In a large project involving many modules, creating a new project could be a major effort.
I appreciate any input someone might offer.
Thanks again,
Soong
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden