On Fri, 2013-01-11 at 17:53 +0900, Keun-O Park wrote:
> Hello Steve,
>
> Much obliged for your explaining this.
> As your guess, there's another path that uses CALLER_ADDR1 without
> CONFIG_PROVE_LOCKING though both lockdep and ftrace's irqsoff tracer
> is turned on. In this case, ftrace's
On Mon, Jan 7, 2013 at 10:41 PM, Steven Rostedt wrote:
>
> On Fri, 2013-01-04 at 17:45 +0900, Keun-O Park wrote:
>
> > With "CFLAGS_REMOVE_unwind.o = -pg" and with CONFIG_PROVE_LOCKING
> > turned on, I confirmed that
> > there's no trace output like Steve mentioned.
> > However, if I turn off
On Mon, Jan 7, 2013 at 10:41 PM, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 2013-01-04 at 17:45 +0900, Keun-O Park wrote:
With CFLAGS_REMOVE_unwind.o = -pg and with CONFIG_PROVE_LOCKING
turned on, I confirmed that
there's no trace output like Steve mentioned.
However, if I turn
On Fri, 2013-01-11 at 17:53 +0900, Keun-O Park wrote:
Hello Steve,
Much obliged for your explaining this.
As your guess, there's another path that uses CALLER_ADDR1 without
CONFIG_PROVE_LOCKING though both lockdep and ftrace's irqsoff tracer
is turned on. In this case, ftrace's
On Fri, 2013-01-04 at 17:45 +0900, Keun-O Park wrote:
> With "CFLAGS_REMOVE_unwind.o = -pg" and with CONFIG_PROVE_LOCKING
> turned on, I confirmed that
> there's no trace output like Steve mentioned.
> However, if I turn off CONFIG_PROVE_LOCKING, "irqsoff" and
> "preemptirqsoff" ftracer prints
On Fri, 2013-01-04 at 17:45 +0900, Keun-O Park wrote:
With CFLAGS_REMOVE_unwind.o = -pg and with CONFIG_PROVE_LOCKING
turned on, I confirmed that
there's no trace output like Steve mentioned.
However, if I turn off CONFIG_PROVE_LOCKING, irqsoff and
preemptirqsoff ftracer prints these lines :
On Fri, Jan 4, 2013 at 1:58 AM, Steven Rostedt wrote:
> On Thu, 2013-01-03 at 16:23 +, Russell King - ARM Linux wrote:
>> On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
>> > On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
>> > > In summary, from what I can
On Fri, Jan 4, 2013 at 1:58 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 2013-01-03 at 16:23 +, Russell King - ARM Linux wrote:
On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
In summary, from
On Thu, 2013-01-03 at 16:23 +, Russell King - ARM Linux wrote:
> On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
> > On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
> > > In summary, from what I can see in the patch, the reason why the ifdefs
> > > are the
On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
> On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
> > In summary, from what I can see in the patch, the reason why the ifdefs
> > are the way they are, and the reason the warning is there has not been
> > addressed;
On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
> >
> > Or something similar, if that's what was done.
>
> No. What I want is some evidence that the patch author is not just
> removing warnings by patching them away, but has thought about why
> the warning is there, and that
On Thu, Jan 03, 2013 at 08:36:05AM -0500, Steven Rostedt wrote:
> On Thu, 2013-01-03 at 20:36 +0900, Keun-O Park wrote:
> > So what have you done about the issue referred in this
> > comment? Or do you
> > believe that fixing warnings (even if they are explicit
> >
On Thu, 2013-01-03 at 20:36 +0900, Keun-O Park wrote:
>
> So what have you done about the issue referred in this
> comment? Or do you
> believe that fixing warnings (even if they are explicit
> #warning statements)
> is far more important than
On Thu, Jan 03, 2013 at 07:12:29PM +0900, kpark3...@gmail.com wrote:
> -#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
> +#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_ARM_UNWIND)
> /*
> * return_address uses walk_stackframe to do it's work. If both
> *
From: sahara
This fixes a warning saying:
warning: #warning "TODO: return_address should use unwind tables"
And, this enables return_address using unwind information. If ARM_UNWIND is
selected, unwind_frame in unwind.c will be called in walk_stackframe.
Signed-off-by: sahara
---
From: sahara keun-o.p...@windriver.com
This fixes a warning saying:
warning: #warning TODO: return_address should use unwind tables
And, this enables return_address using unwind information. If ARM_UNWIND is
selected, unwind_frame in unwind.c will be called in walk_stackframe.
On Thu, Jan 03, 2013 at 07:12:29PM +0900, kpark3...@gmail.com wrote:
-#if defined(CONFIG_FRAME_POINTER) !defined(CONFIG_ARM_UNWIND)
+#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_ARM_UNWIND)
/*
* return_address uses walk_stackframe to do it's work. If both
*
On Thu, 2013-01-03 at 20:36 +0900, Keun-O Park wrote:
So what have you done about the issue referred in this
comment? Or do you
believe that fixing warnings (even if they are explicit
#warning statements)
is far more important than code
On Thu, Jan 03, 2013 at 08:36:05AM -0500, Steven Rostedt wrote:
On Thu, 2013-01-03 at 20:36 +0900, Keun-O Park wrote:
So what have you done about the issue referred in this
comment? Or do you
believe that fixing warnings (even if they are explicit
#warning
On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
Or something similar, if that's what was done.
No. What I want is some evidence that the patch author is not just
removing warnings by patching them away, but has thought about why
the warning is there, and that they've
On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
In summary, from what I can see in the patch, the reason why the ifdefs
are the way they are, and the reason the warning is there has not been
addressed; these
On Thu, 2013-01-03 at 16:23 +, Russell King - ARM Linux wrote:
On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
On Thu, 2013-01-03 at 14:13 +, Russell King - ARM Linux wrote:
In summary, from what I can see in the patch, the reason why the ifdefs
are the way they
22 matches
Mail list logo
