Re: Weird stuff
Re: Weird stuff
- Subject: Re: Weird stuff
- From: Rick Altherr <email@hidden>
- Date: Thu, 13 Mar 2008 11:31:00 -0700
On Mar 13, 2008, at 7:51 AM, Adam Hall wrote:
I was noticing performance problems (100% CPU for Donkey Kong on a
2ghz iMac G5) with Mame OS X vs Mac Mame which ran much faster. I
decided to download the source code to get an idea of what might be
the problem and see if I could help. I then noticed a problem with
Shark. It could not find the source code! The debug build of Mame
OS X out of the box, had debug information turned on, yet shark
could not find the source. I have other simpler projects and just a
couple of source files that do not have frameworks embedded within
them and Shark finds the source for these simpler projects (I
suspect the framework source not being found (even though it has
debug info in it) is the problem with Mame OS X, but I am not sure).
I added the directory for Mame src in the shark source search path
(I assume it looks it subdirectories but just in case I even added
the individual directories) this made no difference and shark just
shows disassembly code. Are there any other settings in XCode other
than turning on debug info that should be done, and is there any
other tool I can use to check if the source information is in fact
linked in , just to TRY and narrow down the problem as being Shark
or gcc?
-Adam
_______________________________________________
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
99% of the time, the problem is that the debug information just isn't
there. The rules are as follows:
- If Shark has source information (part of the debug information), but
can't find the source file, it will prompt you to locate it. If you
don't get this prompt, Shark can't find the source information.
- STABs places the debug information directly in the binary. This
almost always works, but if you run strip on the main binary, it is
removed and Shark can't find something that isn't there.
- DWARF places the debug information in the intermediate .o's
generated during the compilation. The main binary contains references
to those .o's via absolute paths. If the .o's are moved or deleted,
Shark will not find any source information. If static archives (.a's)
are being used, there is a bug in Shark 4.5 that causes it to not find
the source information contained in the .a. Running strip on the main
binary will remove the map to the .o's and Shark won't find any source
information.
- DWARF w/ dSYM places the debug information in a separate file (the
dSYM). Shark will look for a dSYM to be next to the main binary or
the bundle containing the main binary. If it can't find the dSYM, it
won't have any source information. Running strip on the main binary
will have no effect on this method. The debug information is entirely
separate from the main binary. They are tagged with a unique
identifier internally in the dSYM and in the main binary to make sure
that a given dSYM represents a given main binary.
--
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
| References: | |
| | >Weird stuff (From: Adam Hall <email@hidden>) |