Re: Help on Stack trace
Re: Help on Stack trace
- Subject: Re: Help on Stack trace
- From: Arnab Ganguly <email@hidden>
- Date: Mon, 9 Feb 2009 15:27:26 +0530
Do we have any sample code for the implementation of
CrashReporter.app? :))It would be ideal to see the code and implement
similar.
Thanks in advance.
-A
Just to clarify, a stack trace is a list of addresses that indicate the functions that have been called. It contains no symbolic naming.
atos reads the debugging information in the binaries and returns the symbolic name that contains a given address. The underlying mechanisms for reading the various debugging formats and getting the information correct are quite complex and are very easy to get wrong. I suggest you avoid trying to reimplement them if at all possible.
That said, atos is a developer tool and won't be available on a regular installation of OS X. There isn't really a great solution to this problem. To write a suitable replacement means you would need to:
- Read the dyld loaded images list from the target process (much easier if done from inside the process you are backtracing)
- Read the Mach-O header for each loaded image
- Parse the symbol table (nlist) and STABs (also nlist) from the loaded image
- If the STABs are of a particular format (called Debug Maps), parse the DWARF2 information from the referenced .o's
- If the binary contains a UUID load command, look for a dSYM that has the same UUID
- If a suitable dSYM is found, parse the DWARF2 information contained within
- Adjust the offsets for all the parsed symbol information so they correspond to the load address of the loaded image
- Repeat for each image in the dyld loaded image list
--
Rick Altherr
Architecture and Performance Group
email@hidden
_______________________________________________
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