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: Fri, 6 Jun 2008 10:50:16 -0700
On Jun 6, 2008, at 10:44 AM, kwiley wrote:
On Jun 5, 2008, at 5:56 PM, Rick Altherr wrote:
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.
-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
Hmmm, well, I appreciate all the detailed information. However, I
don't think I've done anything wonky like moving or deleting .o
files or stripping debug info out of the executable. I just build
from Xcode and go straight to Start With Performance Tool and Shark
it. I also don't think there is any .o to .a aggregation going on,
so, I'm a little confused about what the problem could be. Is there
any chance Shark simply doesn't know *where* the .o files are. They
are, of course, not in the same directory (by a long shot) as the
executable. The install target (remember I'm building with a
standard makefile with an External Target in Xcode, although I build
with Xcode's Build command instead of on the command line), puts the
executable in a totally different directory.
The funniest thing is, as I said, Shark show source for some
functions, but not others. I find that totally perplexing.
I'll look into dsymutil. "which" found it, so I just need to see
how to use it now. Thanks much.
Cheers!
________________________________________________________________________
Keith Wiley email@hidden http://www.cs.unm.edu/~kwiley
"Yet mark his perfect self-contentment, and hence learn his lesson,
that
to be self-contented is to be vile and ignorant, and that to aspire is
better than to be blindly and impotently happy."
-- Edwin A. Abbott,
Flatland
________________________________________________________________________
There is a slight chance that the compiler encodes the .o's path based
on the path specified for -o. If you use relative paths, that might
confuse things. Xcode tends to use absolute paths for every compiler
invocation. I suspect that something in your Makefile is doing
something that ultimately resolves to one of the problems I
mentioned. It's likely that the reason this affects only a subset of
functions is because they are grouped together and whatever is causing
the problem affects just that group. You might look to see what .o
the functions are in and then look at the compile commands for
those .o's.
If the source is open, I could take a look.
--
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