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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2006/7/27, Thiemo Seufer <ths@xxxxxxxxxxxx>:
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@xxxxxxxxxxxxx>
>
> 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.

But is it really needed to show that foo_wrapper() has been called
before foo() ? The backtrace given by oops is for the first debug
intervention. They don't give a very accurate backtrace but it's
enough to understand what's going on in most cases.

BTW, the same exists with inlined functions. Gcc can inlined function
that are not been marked inlined and these functions won't appear in
any traces...

--
              Franck


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux