Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
2009/2/4 Steven Rostedt : > > >From ftrace.h: > > #ifdef CONFIG_FRAME_POINTER > /* TODO: need to fix this for ARM */ > # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) > # define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1)) > # define CALLER_ADDR2 ((unsigned long)__builtin_return_address(2)) > # define CALLER_ADDR3 ((unsigned long)__builtin_return_address(3)) > # define CALLER_ADDR4 ((unsigned long)__builtin_return_address(4)) > # define CALLER_ADDR5 ((unsigned long)__builtin_return_address(5)) > # define CALLER_ADDR6 ((unsigned long)__builtin_return_address(6)) > #else > # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) > # define CALLER_ADDR1 0UL > # define CALLER_ADDR2 0UL > # define CALLER_ADDR3 0UL > # define CALLER_ADDR4 0UL > # define CALLER_ADDR5 0UL > # define CALLER_ADDR6 0UL > #endif > > Yep! > Ok. 2009/2/4 Anton Vorontsov : > It depends on the architecture. On PowerPC we always have frame pointers, > thus __builtin_return_address(1..) will always work. On x86 it won't work > that way. > > Thanks, > > -- > Anton Vorontsov Thanks for your answers! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
2009/2/4 Anton Vorontsov : > Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they > should select FRAME_POINTER. Otherwise traces are meaningless. > > Signed-off-by: Anton Vorontsov > --- > kernel/trace/Kconfig |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index e2a4ff6..48f7a37 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -86,6 +86,7 @@ config IRQSOFF_TRACER >select TRACE_IRQFLAGS >select TRACING >select TRACER_MAX_TRACE > + select FRAME_POINTER >help > This option measures the time spent in irqs-off critical > sections, with microsecond accuracy. > @@ -108,6 +109,7 @@ config PREEMPT_TRACER >depends on DEBUG_KERNEL >select TRACING >select TRACER_MAX_TRACE > + select FRAME_POINTER >help > This option measures the time spent in preemption off critical > sections, with microsecond accuracy. > @@ -136,6 +138,7 @@ config SCHED_TRACER >select TRACING >select CONTEXT_SWITCH_TRACER >select TRACER_MAX_TRACE > + select FRAME_POINTER >help > This tracer tracks the latency of the highest priority task > to be scheduled in, starting from the point it has woken up. > -- Looks right. BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ? I guess it would only work with the first caller builtin_return_address(0) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] ftrace: fixes for PPC
2008/10/20 Steven Rostedt <[EMAIL PROTECTED]>: > I believe MIPS has the same issues as PPC. Doesn't it use a trampoline > too? No it doesn't seem to. If I'm not wrong, MIPS uses only the elf relocation table to relocate its addresses. > I want to make the generic code handle trampolines a bit better. Do you think there could be a generic approach to handles these trampolines? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] ftrace: fixes for PPC
2008/10/20 Josh Boyer <[EMAIL PROTECTED]>: > That seems like a good plan. Should we mark dynamic ftrace as X86 only > in Kconfig for .28 to prevent people from inadvertently setting it? Hi Josh. There are other arch that support ftrace as well like sh or sparc64 (I'm currently working on an implementation for mips). So the choice would be better between waiting for a fix or disable dynamic ftrace on Kconfig only for PowerPC. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
