[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081031185526.GT28946@ZenIV.linux.org.uk>
Date: Fri, 31 Oct 2008 18:55:26 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: [PATCH] Re: alpha: undefined reference to `save_stack_trace'
On Fri, Oct 31, 2008 at 06:48:22PM +0000, Al Viro wrote:
> On Fri, Oct 31, 2008 at 06:24:11PM +0000, Al Viro wrote:
> > On Fri, Oct 31, 2008 at 07:57:51PM +0300, Alexey Dobriyan wrote:
> > > On alpha-smp-[ny]-debug-y:
> > >
> > > LD .tmp_vmlinux1
> > > kernel/built-in.o: In function `ftrace_trace_stack':
> > > (.text+0x706fc): undefined reference to `save_stack_trace'
> > >
> > >
> > > Somehow STACKTRACE is set despite no STACKTRACE_SUPPORT.
> >
> > select blows, film at 11. TRACING blindly selects STACKTRACE, with a bunch
> > of stuff in kernel/tracing/Kconfig doing select of TRACING. Not just an alpha
> > problem, BTW.
>
> While we are at it, we have that particular turd on allmodconfigs on (at least)
> alpha
> blackfin
> cris
> frv
> h8300
> ia64
> m32r
> m68k
> m68knommu
> mn10300
> parisc
> sparc (32bit one, that is)
> uml/i386
> uml/amd64
> xtensa
>
> We could slap && HAS_STACKTRACE_SUPPORT on all symbols that end up selecting
> TRACING, but that's almost certainly wrong; the thing won't break if we
> simply omit stack trace output on configs that do not have them supported.
> Why do we have that select STACKTRACE there, anyway?
It's too ugly for words, but it does deal with this mess ;-/
Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
---
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index b58f43b..33dbefd 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -25,7 +25,7 @@ config TRACING
bool
select DEBUG_FS
select RING_BUFFER
- select STACKTRACE
+ select STACKTRACE if STACKTRACE_SUPPORT
select TRACEPOINTS
select NOP_TRACER
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists