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 15:01:33 -0700
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