Re: The case of the broken breakpoints
Re: The case of the broken breakpoints
- Subject: Re: The case of the broken breakpoints
- From: Jason Molenda <email@hidden>
- Date: Thu, 31 Dec 2009 16:34:01 -0800
On Dec 31, 2009, at 2:56 PM, Oftenwrong Soong wrote:
> Perhaps there's a hole in my knowledge of debugging but I thought breakpoints are set on addresses, not on symbols.
The majority of breakpoints in Xcode are filename + linenumber breakpoints -- when you click in the breakpoint gutter in the source editor, that breakpoint is communicated to gdb as a file+line breakpoint.
If you add a breakpoint in Xcode by function name (Run > Manage Breakpoints > Add Symbolic Breakpoint), that is sent to gdb as a function name.
The "Load Symbols Lazily" does work the vast majority of the time. What this optimization does is have gdb ignore the symbols of the executable, dylibs, frameworks, and bundles. This improves startup time - gdb does far less work each time it sees a new framework/etc. But because gdb hasn't scanned in any symbolic/debug information, it can't place breakpoints -- it doesn't know function names, it doesn't know files and line numbers. So when Xcode sends a breakpoint ("main.m:15") to gdb, it tells gdb which file contains this breakpoint ("MyApp.app"). gdb then reads all of the symbol and debug information for MyApp and the breakpoint is set.
For small- to medium-sized programs, this optimization is not important. For large programs, programs with a gigabyte of debug information for all their dylibs/frameworks, it is essential or gdb will spend minutes scanning all of the debug information at startup.
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. :)
Of course you don't see posts on the lists from all of cases where lazy symbol loading works - you only see the ones where it has issues - so it can seem like it rarely works. But trust me, in the vast majority of cases, it works correctly and people are unaware of what's going on under the covers.
From the UI, you can see that your breakpoint is "pending" if the breakpoint arrow is yellow/orange/whatever that color is. A pending breakpoint is a breakpoint in a dylib/bundle that is not yet loaded OR it's the case that the dylib/bundle has loaded but Xcode didn't know what bundle/dylib that source file is in and gdb hasn't been told to read the symbol/debug information for it yet.
Another aside, once you pause a debug session gdb will start reading information for frameworks/dylibs/etc on the stack as it walks the threads' stacks. So symbol/debug information may be pulled in mid-session and breakpoints that were formerly marked as "pending" may resolve to actual breakpoints at that point.
If you want to see ALL of the details of what's going on, put "set verbose 1" in your ~/.gdbinit file. You won't want to leave it there for long.
> There are other interesting things I've seen discussed, for example, a suggestion to change the debug information format to Dwarf with dsym file, which I don't quite understand given that the purpose of a dsym file is to provide symbol information separately from the executable, e.g., to keep around after distributing a stripped Release build.
There should be no difference between DWARF debugging and DWARF+dSYM debugging in this regard. As you say, it is critical to preserve the dSYM for any binary you release (and will want to debug in the future) but if you're debugging an executable on your own computer, DWARF alone will work fine.
J _______________________________________________
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