Re: Help on Stack trace
Re: Help on Stack trace
- Subject: Re: Help on Stack trace
- From: Peter O'Gorman <email@hidden>
- Date: Fri, 06 Feb 2009 11:18:37 -0600
Arnab Ganguly wrote:
> Hi ,
> Thanks for the email and update.What if I use dladdr system call with
> program counter pointer and fetch the info.dli_sname to get the symbol
> name?Is it going to be inaccurate or not valid at all?
> Regards
dladdr will give you the name and address of "the nearest run-time
symbol with a value less than or equal to addr". Where run-time symbol,
means exported global symbol.
So if you have:
void foo(void) {
...
}
static void bar(void) {
...
}
If you give dladdr and address somewhere in bar, the "nearest run-time
symbol" that dladdr will return is "foo", so you know foo + offset from
foo. That may be enough information for you, but probably not.
Peter
> -A
>
> On Thu, Feb 5, 2009 at 11:48 PM, Rick Altherr <email@hidden
> <mailto:email@hidden>> wrote:
>
>
> On Feb 5, 2009, at 6:12 AM, Arnab Ganguly wrote:
>
> Hi All,
> Proably the same question I am asking again. atos is fine to use
> for getting the stack trace.But is it going to be available on
> all Mac OSX system? What alternative can be taken when atos is
> not available to get that detailed information.Considering Mac
> version as Tiger and I have used dladdr and
> __cxxabiv1::__cxa_demangle but not getting that much clear
> symbol information compared to atos.My code is on Objective-C.
> Thanks
> -A _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden
> <mailto:email@hidden>)
> Help/Unsubscribe/Update your Subscription:
> <http://40apple.com>
>
> This email sent to email@hidden <mailto:email@hidden>
>
>
>
> 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
>
--
Peter O'Gorman
http://pogma.com
_______________________________________________
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