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: "Stuart A. Malone" <email@hidden>
- Date: Fri, 8 Jul 2005 10:56:36 -0400
Jim,
I've submitted bug report #4173909 about this problem, and attached
both debug builds of our application to the bug report. I hope
you'll be able to take a look at it.
Yes, the inline function being called is MacFramework::Window::Hide()
in Window.h. The function is defined as:
namespace MacFramework {
inline void Window::Hide()
{
::HideWindow(mWindow);
}
}
My guess is that it is mentioned in several other places in both
builds, it's just that near this particular call to it (a) I was
trying to set a breakpoint, and (b) the return .SOL to the main
PreferencesSheet.cpp file is missing. I haven't checked to see if
other calls to this function are triggering the same problem.
Let me know if I can provide any additional information.
Best wishes,
--Stuart A. Malone
Llamagraphics, Inc.
Makers of Life Balance personal coaching software
http://www.llamagraphics.com/
On Jul 6, 2005, at 6:01 PM, Jim Ingham wrote:
Stuart,
If it's not a problem, both would help. Is the function
MacFramework::Window::Hide() in Window.h (sounds like it)? It's
looking like the linker is mangling the debug info somehow. Though
it's odd, if the Hide function is in Window.h, the first version is
wrong NOT to have ths SLINE info, and the second wrong not to have
the concluding SOL... Anyway, I'll know more if I can see the two
complete versions.
Thanks for following up with this.
Jim
On Jul 6, 2005, at 11:57 AM, Stuart A. Malone wrote:
Hi Jim,
Thanks for getting back to us on this one. Here's some additional
information.
On Jul 6, 2005, at 1:11 PM, Jim Ingham wrote:
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.
Luckily, as a three-person company, we get to make up our own
policies. We'll file a bug with a debug build showing the problem.
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.
I decided to give this a try, and ran the command on two different
debug builds: a "good" build where the inline function was
commented out and the debugger works fine, and a "bad" build where
the inline function was called and the debugger goes to the wrong
file. I then stripped the hex offsets from the two files in emacs
to avoid trivial mismatches, and got the following:
diff good-strip.txt bad-strip.txt
47047c47047,47054
< - 00 0165 PSYM this:p(0,1358)=k(0,586)
---
> - 07 0000 SOL /Projects-3-2-x/Life Balance/Mac/../../Mac/
Interface/src/Window.h
> - 07 0153 SLINE
> - 07 0155 SLINE
> - 07 0156 SLINE
> - 07 0153 FUN _ZN12MacFramework6Window4HideEv:F(0,19)
> - 00 0153 PSYM this:p(0,1358)=k(0,586)
> - 00 0000 FUN
> - 00 0165 PSYM this:p(0,1358)
47459a47467
> - 01 007c SLINE
47699a47708,47709
> s __ZN12MacFramework6Window4HideEv
> s __ZN12MacFramework6Window4HideEv.eh
It looks to us like the "bad" version does an SOL to Window.h, but
fails to do a return SOL to the main source file
PreferencesSheet.cpp after the inline function definition is
done. So it looks to us like the assembler output and the
contents of the binary don't agree.
When we file our bug report, would it be helpful to have both the
"good" and the "bad" binaries, or do you only want the bad one?
Best wishes,
--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