All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: davidm@hpl.hp.com
Cc: Christoph Hellwig <hch@infradead.org>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] generic show_stack facility
Date: Fri, 29 Mar 2002 09:36:26 -0800	[thread overview]
Message-ID: <3CA4A61A.A844E21B@zip.com.au> (raw)
In-Reply-To: <20020329160618.A25410@phoenix.infradead.org> <15524.40817.306204.292158@napali.hpl.hp.com>

David Mosberger wrote:
> 
> ..
>   Christoph> So your suggestion is to move the other architectures to
>   Christoph> the ia64 prototype or to not have an
>   Christoph> architecture-independand stack-traceback facility at all?
> 
> I haven't done such an investigation.  I believe the ia64 prototype is
> reasonable and probably implementable on all platforms that can unwind
> the stack in the first place, but before making a change to the stable
> kernel API, I'd think someone would have to investigate this a bit
> further.
> 

The way I ended up resolving these sorts of issues was to 
make the generic function

	void dump_stack(void);

under the (hopefully valid) assumption that all architectures
can somehow, in some manner, manage to spit out something
useful.

For a transitional/compatibility think, there's lib/dump_stack.c
which just prints "I'm broken".

Here's the diff.  Comments?


--- 2.4.19-pre4/include/linux/kernel.h~aa-094-dump_stack	Tue Mar 26 23:11:27 2002
+++ 2.4.19-pre4-akpm/include/linux/kernel.h	Tue Mar 26 23:11:27 2002
@@ -106,6 +106,8 @@ extern int oops_in_progress;		/* If set,
 extern int tainted;
 extern const char *print_tainted(void);
 
+extern void dump_stack(void);
+
 #if DEBUG
 #define pr_debug(fmt,arg...) \
 	printk(KERN_DEBUG fmt,##arg)
--- /dev/null	Thu Aug 30 13:30:55 2001
+++ 2.4.19-pre4-akpm/lib/dump_stack.c	Tue Mar 26 23:11:27 2002
@@ -0,0 +1,13 @@
+/*
+ * Provide a default dump_stack() function for architectures
+ * which don't implement their own.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+void dump_stack(void)
+{
+	printk(KERN_NOTICE
+		"This architecture does not implement dump_stack()\n");
+}
--- 2.4.19-pre4/lib/Makefile~aa-094-dump_stack	Tue Mar 26 23:11:27 2002
+++ 2.4.19-pre4-akpm/lib/Makefile	Tue Mar 26 23:11:27 2002
@@ -10,7 +10,8 @@ L_TARGET := lib.a
 
 export-objs := cmdline.o dec_and_lock.o rwsem-spinlock.o rwsem.o rbtree.o
 
-obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o bust_spinlocks.o rbtree.o
+obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o \
+		bust_spinlocks.o rbtree.o dump_stack.o
 
 obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
 obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
--- 2.4.19-pre4/kernel/ksyms.c~aa-094-dump_stack	Tue Mar 26 23:11:27 2002
+++ 2.4.19-pre4-akpm/kernel/ksyms.c	Tue Mar 26 23:11:27 2002
@@ -560,3 +560,6 @@ EXPORT_SYMBOL(init_task_union);
 
 EXPORT_SYMBOL(tasklist_lock);
 EXPORT_SYMBOL(pidhash);
+
+/* debug */
+EXPORT_SYMBOL(dump_stack);
--- 2.4.19-pre4/arch/i386/kernel/traps.c~aa-094-dump_stack	Tue Mar 26 23:11:27 2002
+++ 2.4.19-pre4-akpm/arch/i386/kernel/traps.c	Tue Mar 26 23:11:27 2002
@@ -186,6 +186,14 @@ void show_stack(unsigned long * esp)
 	show_trace(esp);
 }
 
+/*
+ * The architecture-independent backtrace generator
+ */
+void dump_stack(void)
+{
+	show_stack(0);
+}
+
 void show_registers(struct pt_regs *regs)
 {
 	int i;

  parent reply	other threads:[~2002-03-29 17:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-29 15:23 [PATCH] generic show_stack facility Christoph Hellwig
2002-03-29 15:46 ` David Mosberger
2002-03-29 16:06   ` Christoph Hellwig
2002-03-29 17:08     ` David Mosberger
2002-03-29 17:16       ` arjan
2002-03-29 18:25         ` David Mosberger
2002-03-30 10:06           ` Kai Henningsen
2002-03-29 17:36       ` Andrew Morton [this message]
2002-03-29 18:26         ` David Mosberger
2002-03-29 18:34         ` Christoph Hellwig
2002-03-29 18:41           ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2002-03-30  3:05 Keith Owens
2002-03-30  3:31 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CA4A61A.A844E21B@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=davidm@hpl.hp.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.