site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AcX1O9vCJc3TJzopRb+cnHc17xZHZA== Thread-topic: Leaf vs. Non-leaf functions & crash reporting I'm trying to improve our crash reporting system and have a conundrum that Apple seems to have solved. When we're reading information about another thread stack, we have the ppc_thread_state_t. We know the current pc is srr0, but we don't know whether the lr points to something valid or not. In the leaf function case, it does, and the stack pointer (r1) points to the parent's frame. However, in the non-leaf function case, it's either undefined or points immediately after the last function call that had been made, and the stack pointer (r1) points to the current frame. The current behavior of the stack crawl is to be verbose and treat both srr0 and lr as valid stack crawl pcs, and leave it to the humans to sort it out later. However, it appears that Apple's crash reporter manages to figure it out nicely. I've been staring at it for some time, but I cannot figure out how to do it that doesn't involve some code inspection to see if lr points to some code between ssr0 and the prolog of the function ssr0 is in (and that's assuming it has a prolog). Is there some nifty trick (without the use of stabs or traceback tables or sym files) to handle this case? Currently stumped, nh P.S., Does apple have any plans to export the functionality the crash reporter uses just so we don't have to have our own version? :) ---- Nathan Herring MacBU SDE/Development _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com