Re: Shark is losing source code
Re: Shark is losing source code
- Subject: Re: Shark is losing source code
- From: Rick Altherr <email@hidden>
- Date: Thu, 5 Jun 2008 17:56:15 -0700
On Jun 5, 2008, at 4:06 PM, kwiley wrote:
Is this the right group to post Shark questions to?
My code was built with -O -g -DNDEBUG, although note that I have the
exact same problem if I build with -g alone.
I run my executable with Shark, wait for it, and get the typical
Shark results. I double-click various rows in the profile view to
see the associated code. Now, the weird part is that for *some*
files it shows the code, but for others it only shows the assembly.
If I look at the build transcript, the files in question were
definitely built with -g.
This is a rather peculiar build I admit, because it is an external
target that invokes make and basically doesn't use Xcode for much
other than editing, but nevertheless, what's going on?
I realize this post probably isn't sufficient to solve the problem,
but does anyone know how I should start working on this? I don't
really have any ideas?
Thanks.
________________________________________________________________________
Keith Wiley email@hidden http://www.cs.unm.edu/~kwiley
"Never underestimate a computer program's ability to enter a loop that
counts to a quadrillion. Furthermore, never underestimate a
programmer's ability to accidentally put a print out statement inside
that loop."
-- Keith Wiley
________________________________________________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
-g in Xcode 3 uses DWARF for debugging, but in an effort to reduce
binary size, it leaves the DWARF information in the
intermediate .o's. When shark looks at the executable, it finds a set
of debug information that basically says "function a, which is at this
address, has debug info in /foo/a.o". To help uniquely identify
the .o's, the filesystem timestamp for the .o is also encoded in the
binary.
What does this mean to you? If the .o's are deleted, Shark can't read
the debug info from them. If the .o's are moved to a different
folder, Shark can't find it. If the .o's are modified after the
compile, Shark won't use it. If you strip debug information on the
main executable, Shark won't know which .o's to look in. Lastly,
there is a bug in Shark 4.5 where the wrong timestamp is used when
validating a .o that was aggregated into a .a before being linked into
the final executable. That bug has been fixed internally and will be
incorporated into our next release.
As a workaround, you can use dsymutil to generate a .dSYM file.
The .dSYM is essentially an aggregation of all the debug information
contained in the .o's. If you generate one successfully and place it
in the same folder as the executable, Shark will automatically read
the debug information from the .dSYM. This can be used to work around
the .a bug in Shark.
--
Rick Altherr
Architecture and Performance Group
email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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