linux-mips
[Top] [All Lists]

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

To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Subject: Re: [PATCH] dump_stack() based on prologue code analysis
From: Thiemo Seufer <ths@networkno.de>
Date: Thu, 27 Jul 2006 20:12:45 +0100
Cc: David Daney <ddaney@avtrex.com>, Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <cda58cb80607271151n2dcfe64cn4cb1ecca3ece6b1e@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060726.232231.59465336.anemo@mba.ocn.ne.jp> <44C8EFE2.4010102@avtrex.com> <20060727170305.GB4505@networkno.de> <cda58cb80607271151n2dcfe64cn4cb1ecca3ece6b1e@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.12-2006-07-14
Franck Bui-Huu wrote:
> 2006/7/27, Thiemo Seufer <ths@networkno.de>:
> >David Daney wrote:
> >> Atsushi Nemoto wrote:
> >> >Instead of dump all possible address in the stack, unwind the stack
> >> >frame based on prologue code analysis, as like as get_chan() does.
> >> >While the code analysis might fail for some reason, there is a new
> >> >kernel option "raw_show_trace" to disable this feature.
> >> >
> >> >Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
> >>
> >> Let me start by saying I have not analyzed how all this code works, but
> >> I have done something similar in user space.
> >>
> >> Since the kernel ABI does not use gp, many functions may not have a
> >> prolog (especially when compiled with newer versions of GCC).  In the
> >> user space case, most leaf functions have no prolog.  For the kernel I
> >> would imagine that many non-leaf functions (simple non-leaf functions
> >> that do only a tail call) would also not have a prolog.
> >
> >Non-leaves have to save/restore $31 somewhere, so there should be a
> >prologue.
> >
> 
> That's no always true. Consider this simple example:
> 
> void foo_wrapper(int a, int b)
> {
>        /* doing some checkings */
>        [...];
>        foo(a,b);
> }
> 
> void foo(int a, intb)
> {
>        [...];
> }
> 
> In foo_wrapper(), gcc will generate a "j" instruction (well I guess)
> because once foo() is called and is finished, there's no needs to
> return back to foo_wrapper(). In that case, foo_wrapper() won't have a
> prologue.

Well, with tail call optimisation it isn't a true nested function any
more, the compiler can even reorder and/or combine functions in more
creative ways.

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


Thiemo

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