Re: Ftrace for Microblaze - notrace
From: Michal Simek
Date: Tue Nov 03 2009 - 13:13:33 EST
Steven Rostedt wrote:
On Tue, 2009-11-03 at 17:45 +0100, Michal Simek wrote:
Steven Rostedt wrote:
Is there any manual or instruction which functions are dangerous and
The next thing is about annotation notrace. I look at all arch. Is there
any algorithm which function should use it? I think that this could be a
reason why I my kernel freeze when enable function tracer.Probably.
I tested to add -pg flag for process.c file and after it kernel freeze
too. Is it mean that problem could be there?
No there's no manual. It varies from arch to arch. Hmm, maybe I'll
update the current doc to have some of the issues that come with it.
(more info farther down)
yes, will be helpful - anyway I found missing references to
And that will keep the process.c from being compiled with it. There mayDo you know why they exclude it?
be other files in the arch that should not have it. There's several in
x86 and in PowerPC.
I did the ports for x86 and PowerPC so I guess I'm the best to answer
I hope so.
In arch/x86 we have these removing -pg:
tsc.o, rtc.o - Do not trace clock output. The tracer itself uses it.
Even though it protects against recursion, it is a big overhead to trace
something within the tracer.
paravirt-spinlocks.o - paravirt does crazy things with locks and such,
but overwriting text. Don't add mcount to them and overwrite the text
with the ftrace facility.
ftrace.o - well duh ;-)
early_printk.o - This is mostly used for debugging, don't trace it.
cpu/common.o - This is used in early stages of boot up of secordary
CPUs. As well as used in hot plug. Simply using something like
smp_processor_id() can crash the kernel here. The tracer code uses that,
so don't trace it.
Xen has a bunch that they added, and I think that's also because they do
funny things too.
For powerpc, we have:
cputable.o, prom_init.o, btext.o and prom.o that are all very sensitive
with boot up code. Simply calling mcount here can crash the system. But
this prevents boot up. It does not lock up the kernel when we enable
ftrace.o - again, this should be obvious.
time.o - this is the same reason we don't trace tsc and rtc in x86.
ok In general - all timing functions and function which are related with
startup code - called only once before turning on irqs - there are a lot
of functions. I understand that make no sense to trace that files. And
plus all debugging functions. And function which uses locks.
Can I use any special debug features? I mean I look at kernel.h and
there are some trace_printk function - but they don't work for me. Is it
possible to use them or not?
Should work. That's not arch dependent. But you need to have some ftrace
enabled. Enable CONFIG_CONTEXT_SWITCH_TRACER, and trace_printk should
work. That writes to the ring buffer and you can see the output
It could be nice features but in case that you have command line and you
can read that trace debug output. I mean any printk messages - which not
contain any trace facility - just pure printk to console. Are that
messages written to any place which could be read from debuger? Like log
buffer? Is there any place for them?
The second things is that I haven't implemented save_stack_trace
function - it is just while(1) loop. My kernel not jumps to this
function that's why I am not interested to implement it. Am I right that
ftrace code don't use it? Or the standard behavior is that ftrace code
use this function and really care about. Does your kernel use that function?
From my test I don't understand MCOUNT_INSN_SIZE - and which function
doesn't care about. There is this line of pseudocode in your doc
(unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;) but what
the reason is to do that. If I understand correct selfpc and frompc just
give addresses which functions called that mcount and has impact to log.
I mean that if that address is not proper begin of function is found
(not sure if the code do it or not) function name (and function) which
contain that address. Or is there any special reason why to substract
that MCOUNT_INSN_SIZE - for timing or anything like that?
I simple just not find any reason for it. And I believe that don't have
connection with my problem.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/