Re: Shark is losing source code
Re: Shark is losing source code
- Subject: Re: Shark is losing source code
- From: kwiley <email@hidden>
- Date: Fri, 6 Jun 2008 11:48:04 -0700
On Jun 6, 2008, at 11:22 AM, Rick Altherr wrote:
On Jun 6, 2008, at 11:13 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.
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
Are there any circumstances under which the dsymutil approach would
not work...because I tried it. :-) I ran it on the executable and
it produces a .dSYM file next to the executable. Shark's behavior
didn't change, it still showed only assembly for some of the
functions. Does that make sense?
Possibly. That means that isn't the .a bug in Shark. dsymutil is
doing roughly the same thing as Shark. It reads the map from the
main executable and then reads the .o's. If it can't find the .o's,
they will be missing. You might try --verbose to see if it provides
any insight on what is going wrong. I suspect either a missing/
moved .o or a source file that isn't built with -g.
--
Rick Altherr
Architecture and Performance Group
email@hidden
I ran dsymutil verbosely and it listed all of the .o files without
incident. Basically, there were hundreds of entries of the form:
Parsing '/path_to_object_directory/libFile.a(objectFile.o)'
I was incorrect about the .o/.a files. The build system does indeed
pack each directory of .o files into a .a file and then conglomerate
the .a files into an executable.
...but the mystery remains. The .o files were compiled with -g,
the .o and .a files all still exist, dsymutil produces no errors, even
in verbose mode...yet Shark shows source code for some files, but not
others. I will investigate whether the problem is unique to
certain .a files (or directory groups of .o files), but I still don't
see how any of them can differ from others, i.e., why some work and
others don't. I'll see what I can find.
Thanks again.
________________________________________________________________________
Keith Wiley email@hidden http://www.cs.unm.edu/~kwiley
"And what if we picked the wrong religion? Every week, we're just
making God madder and madder!"
-- Homer Simpson
________________________________________________________________________
_______________________________________________
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