Inline functions get debugger confused about source files
Inline functions get debugger confused about source files
- Subject: Inline functions get debugger confused about source files
- From: "Stuart A. Malone" <email@hidden>
- Date: Wed, 6 Jul 2005 11:43:53 -0400
Hello Xcoders,
We've encountered a problem in the Xcode 2.1 debugger, and we've
partly tracked it down, but not enough to produce a simple test
case. We'd like some advice on how we can narrow down the problem
further, or provide folks at Apple with enough information that
they'd be able to reproduce the problem there.
The problem occurs with C++ source files that contain calls to inline
functions. In some (but not all) cases, these calls will cause the
debugger to become confused about which file a given line of code is
in. The symptoms are:
1. Breakpoints set in the file are never hit.
2. If you force a break by calling DebugStr, the debugger will
display the correct line
of code but IN THE WRONG FILE. The wrong file seems to
always be one of the header
files containing an inline function.
The very strange thing about this bug is that when it happens, it
seems to affect functions that are defined BEFORE the calls to the
inline functions. For instance, if you have:
void foo() {
DebugStr("\pfoo");
}
void bar() {
inline_function();
}
when the debugger stops at the DebugStr, it will display the header
file for inline_function(). Commenting out the call to
inline_function() or making the function not be declared inline will
cause the debugger to display the correct source file.
The other things we've discovered about the problem are:
1. It doesn't seem to be affected by the optimization level.
2. It doesn't seem to be affected by the -fno-inline flag.
3. Not all inline function calls trigger the problem.
As far as we can tell, the .stabs and .stabd directives in the
assembly output for the file look fine, so either the problem is in
the actual binary symbol table, or the bug is in how gdb is reading
the debugging information. We've taken a look at the gdb bug
database, but haven't seen anything that seems exactly like this.
Unfortunately, our attempts to reproduce the problem using a small
test application have failed. We're only seeing the problem with our
full-blown Carbon application, ported over from CodeWarrior.
So, can anyone suggest how we might narrow down this problem further,
or report it even more clearly to Apple?
Thanks,
--Stuart A. Malone
Llamagraphics, Inc.
Makers of Life Balance personal coaching software
http://www.llamagraphics.com/
_______________________________________________
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