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: Wed, 6 Jul 2005 14:57:59 -0400
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