[Top] [All Lists]

Re: [PATCH] dump_stack() based on prologue code analysis

To: Nigel Stephens <>
Subject: Re: [PATCH] dump_stack() based on prologue code analysis
From: David Daney <>
Date: Fri, 28 Jul 2006 11:32:23 -0700
Cc: Atsushi Nemoto <>,,,,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
Nigel Stephens wrote:

David Daney wrote:

Atsushi Nemoto wrote:

On Thu, 27 Jul 2006 20:12:45 +0100, Thiemo Seufer <> wrote:

IOW, binary analysis can't be expected to provide full accuracy, but
we can live with a reasonable approximation, I think.

Yes, this is a starting point.

The patch (and current mips get_wchan() implementation) tries to do is
what I used to do to analyze stack dump by hand.

1. Determine PC and SP.
2. Disassemble a function containing the PC address.
3. If the function is leaf, make use RA for new PC.

This was always the tricky part for me. How do you know if the function is a leaf?

I think that if you cannot find a store instruction which saves RA to the stack -- either because it's a real leaf and there is no such store, or because the PC hasn't yet reached the store instruction -- then in both cases it can be treated as a leaf.

Presumably you are walking the code back from the PC until you find the prolog. How would you tell if you had gone past the beginning of a leaf function? If you find a j $31 you might assume that it was the end of the previous function.

But that does not work if you are in a function that has multiple return points. On encountering a j $31 you have no way of telling if you are in a leaf function or a non-leaf function with multiple return points.

I may be missing something here, if you know of a failure-proof manner to detect leaf functions I would appreciate hearing what it is.

David Daney.

<Prev in Thread] Current Thread [Next in Thread>