Re: Inline functions get debugger confused about source files
Re: Inline functions get debugger confused about source files
- Subject: Re: Inline functions get debugger confused about source files
- From: Jim Ingham <email@hidden>
- Date: Wed, 6 Jul 2005 10:11:12 -0700
Stuart,
Unless you can get together a small example that shows the problem
(which it sounds like you aren't having much luck with) I will
probably have to look at the debug information in your executable.
Looking at just the .stab* info in the .s files doesn't tell the
whole picture, because the linker also messes with debug info.
I don't know what your company's policies are, but if you can get me
a debug version of your app, and instructions on what to do to show
the problem, I can probably at least tell what is going on. I don't
need the sources or project to start looking at the problem. If we
discover it is a debug info bug, the compiler guys may end up needing
more info, but to start with, that's all I need.
If you are allowed to give me this much, then please file a bug and I
will have a look.
Otherwise, if you want to look at it more, use the "nm -ap
<MyBinary>" command to dump the stabs as they exist in the binary.
The way gdb does address to source line lookup is to look in the
SLINE stabs for the address of the PC. Then the source file for
inlined functions is usually given by the nearest SOL or SO stab
above the SLINE stab for that address in the debug info. You could
look and see if there is some obvious problem there (like a missing
or incorrect SOL or whatever). But tracking this down can be non-
trivial.
Jim
On Jul 6, 2005, at 8:43 AM, Stuart A. Malone wrote:
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
_______________________________________________
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