[patch] dump_stack() cleanup, BK-curr

[patch] dump_stack() cleanup, BK-curr

[Ingo Molnar]

i think it is quite unnecessery to dump the top portion of the stack in
dump_stack(). What matters for all these places (such as the atomic
schedule checker) is the actual backtrace - the printed stack only
contains the local variables of schedule() - not quite helpful for 99.9%
of the cases.

And yet another argument to skip the dumping of the stack: many people
have written down such dumps from screen - including the quite useless
'Stack:' information.

The attached (tested) patch modifies x86's dump_stack() to print out the
much friendlier backtrace. The patch also adds one more whitespace after
the numeric EIP value. The old dump looked this way:

bad: scheduling while atomic!
Stack: ffffffff c041c72f 0000006a 00000068 000000f0 c13e1f28 c04c49c0 c13e1f28
       c02a4099 c04c49c0 000000f0 00000000 00003104 c012592e 00003104 00003104
       ffffffff 34000286 00000282 00000000 00000000 c13e1f28 c04c49c0 c04c4468
Call Trace:
 [<c011f009>]sys_gettimeofday+0x89/0x90
 [<c0113e40>]do_page_fault+0x0/0x49e
 [<c0107d63>]syscall_call+0x7/0xb

the new output is:

bad: scheduling while atomic!
Call Trace:
 [<c011f009>] sys_gettimeofday+0x89/0x90
 [<c0113e40>] do_page_fault+0x0/0x49e
 [<c0107d63>] syscall_call+0x7/0xb

much nicer and much more compact i think.

(The stack dump can still be useful in a number of other situations, so
having it in the real oops output is still good i think.)

	Ingo

--- linux/arch/i386/kernel/traps.c.orig	Wed Oct  2 11:07:25 2002
+++ linux/arch/i386/kernel/traps.c	Wed Oct  2 11:14:12 2002
@@ -144,7 +144,7 @@
 	while (((long) stack & (THREAD_SIZE-1)) != 0) {
 		addr = *stack++;
 		if (kernel_text_address(addr)) {
-			printk(" [<%08lx>]", addr);
+			printk(" [<%08lx>] ", addr);
 			print_symbol("%s\n", addr);
 		}
 	}
@@ -189,7 +189,9 @@
  */
 void dump_stack(void)
 {
-	show_stack(0);
+	unsigned long stack;
+
+	show_trace(&stack);
 }
 
 void show_registers(struct pt_regs *regs)

Re: [patch] dump_stack() cleanup, BK-curr

[Martin J. Bligh]

>  void dump_stack(void)
>  {
> -	show_stack(0);
> +	unsigned long stack;
> +
> +	show_trace(&stack);
>  }

Doesn't this mean that dump_stack no longer dumps the stack?
(seems somewhat counter-intuitive)

Can't code which only wants a trace just call show_trace instead?

M.

Re: [patch] dump_stack() cleanup, BK-curr

[Daniel Phillips]

On Wednesday 02 October 2002 11:22, Ingo Molnar wrote:
> The attached (tested) patch modifies x86's dump_stack() to print out the
> much friendlier backtrace.

How about calling it backtrace(), since that's now what it is.

-- 
Daniel

[OT] backtrace

[Padraig Brady]

Daniel Phillips wrote:
> On Wednesday 02 October 2002 11:22, Ingo Molnar wrote:
> 
>>The attached (tested) patch modifies x86's dump_stack() to print out the
>>much friendlier backtrace.
> 
> How about calling it backtrace(), since that's now what it is.

Sorry to go off topic but this tip is just too useful IMHO.
You can do the same in userspace with glibc. Details here:
http://www.iol.ie/~padraiga/backtrace.c

Pádraig.

Re: [OT] backtrace

[Keith Owens]

On Thu, 03 Oct 2002 09:31:06 +0100, 
Padraig Brady <padraig.brady@corvil.com> wrote:
>Sorry to go off topic but this tip is just too useful IMHO.
>You can do the same in userspace with glibc. Details here:
>http://www.iol.ie/~padraiga/backtrace.c

info libc, /backtrace.

     Note that certain compiler optimisations may interfere with
     obtaining a valid backtrace.  Function inlining causes the inlined
     function to not have a stack frame; tail call optimisation
     replaces one stack frame with another; frame pointer elimination
     will stop `backtrace' from interpreting the stack contents
     correctly.

Most architectures compile with -fomit-frame-pointer (except for ARM
where RMK does it differently).  Neither gdb not glibc can cope with
kernel code built with -fomit-frame-pointer.  See the horrible
heuristics kdb has to apply to get any sort of backtrace on i386.

Re: [OT] backtrace

[Mike Galbraith]

At 07:38 PM 10/3/2002 +1000, Keith Owens wrote:
>On Thu, 03 Oct 2002 09:31:06 +0100,
>Padraig Brady <padraig.brady@corvil.com> wrote:
> >Sorry to go off topic but this tip is just too useful IMHO.
> >You can do the same in userspace with glibc. Details here:
> >http://www.iol.ie/~padraiga/backtrace.c
>
>info libc, /backtrace.
>
>      Note that certain compiler optimisations may interfere with
>      obtaining a valid backtrace.  Function inlining causes the inlined
>      function to not have a stack frame; tail call optimisation
>      replaces one stack frame with another; frame pointer elimination
>      will stop `backtrace' from interpreting the stack contents
>      correctly.
>
>Most architectures compile with -fomit-frame-pointer (except for ARM
>where RMK does it differently).  Neither gdb not glibc can cope with
>kernel code built with -fomit-frame-pointer.  See the horrible
>heuristics kdb has to apply to get any sort of backtrace on i386.

IIRC, r~ once mentioned that it was going to get worse. He also mentioned 
dwarf2 (sp) as a possible solution.  Did you ever look into that?

         -Mike

(I didn't.  Elf->Dwarf transmogrification of kernel is way out of my league)

Re: [OT] backtrace

[Russell King]

On Thu, Oct 03, 2002 at 12:03:27PM +0200, Mike Galbraith wrote:
> At 07:38 PM 10/3/2002 +1000, Keith Owens wrote:
> >Most architectures compile with -fomit-frame-pointer (except for ARM
> >where RMK does it differently).  Neither gdb not glibc can cope with
> >kernel code built with -fomit-frame-pointer.  See the horrible
> >heuristics kdb has to apply to get any sort of backtrace on i386.
> 
> IIRC, r~ once mentioned that it was going to get worse. He also mentioned 
> dwarf2 (sp) as a possible solution.  Did you ever look into that?

There was the offer by someone to supply some code, which as per usual
came to nothing.

Therefore its just a bad rumour as far as I'm concerned.  I can't do
everything, my days are full enough as it is.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [OT] backtrace

[David Mosberger-Tang]

>>>>> On Thu, 03 Oct 2002 11:50:03 +0200, Keith Owens <kaos@sgi.com> said:

  Keith> Most architectures compile with -fomit-frame-pointer (except
  Keith> for ARM where RMK does it differently).  Neither gdb not
  Keith> glibc can cope with kernel code built with
  Keith> -fomit-frame-pointer.  See the horrible heuristics kdb has to
  Keith> apply to get any sort of backtrace on i386.

Keith knows this, but just to be clear: there is no problem unwinding
across functions compiled with -fomit-frame-pointer on ia64.  (Other
platforms could do the same if they took advantage of DWARF2 unwind
info.)

	--david