lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1257266154.31359.14.camel@localhost.localdomain>
Date:	Tue, 03 Nov 2009 11:35:54 -0500
From:	Steven Rostedt <srostedt@...hat.com>
To:	monstr@...str.eu
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org,
	John Williams <john.williams@...alogix.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: Ftrace for Microblaze - notrace

On Tue, 2009-11-03 at 14:32 +0100, Michal Simek wrote:
> Hi Thomas, Ingo, Steven and others
> 
> I am working on ftrace support for Microblaze. I have done basic ftrace
> support - initcall, kmemtrace and other.
> Currently I am working on function trace support.  I did asm code as is
> written in Documentation/trace/ftrace-design.txt.
> 
> I have two poins/questions.
> 
> I desided to use HAVE_FUNCTION_TRACE_MCOUNT_TEST - just test 
> function_trace_stop in asm code - that shouldn't be a problem.

Yeah, and if you don't have that, it is taken care of in the generic
code too.

> 
> I disable -pg in main Makefile because not work for me (more info below) 
> and I enable it just for two file in arch/microblaze (irq.c and intc.c) 
> - recompile kernel and test. Log is below and you can see that I am able 
> to see output for function. That's why I think that my mcount function 
> should be correct. Am I right?
> 
> uclinux login: root
> Password:
> # cd ; mkdir /debug; mount -t debugfs none /debug; cat 
> /debug/tracing/available_
> tracers; echo function > /debug/tracing/current_tracer;echo 1 > 
> /debug/tracing/t
> racing_enabled;cat /debug/tracing/trace | head -n 10
> wakeup_rt wakeup function sched_switch nop
> # tracer: function
> #
> #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
> #              | |       |          |         |
>                sh-52    [000]   184.940000: irq_call <-do_IRQ
>                sh-52    [000]   184.940000: do_IRQ <-get_irq
>                sh-52    [000]   184.940000: handle_level_irq <-intc_mask_ack
>                sh-52    [000]   184.950000: handle_level_irq 
> <-intc_enable_or_unmask
>                sh-52    [000]   184.950000: do_IRQ <-get_irq
>                sh-52    [000]   184.950000: handle_level_irq <-intc_mask_ack
> #
> 
> 
> When is used -pg flag kernel stops when I enable function tracer.
> Interesting is that freeze than I setup function tracing (echo function 
>  > .../current/tracer). Is it correct behavior? I think that trace 
> should start after (echo 1>  .../tracing_enabled).

No, tracing_enabled is default on and should not be used (may go away).
Tracing starts as soon as you echo function into current_tracer.

> 
> 
> 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.
>
> I tested to add -pg flag for process.c file and after it kernel freeze 
> too. Is it mean that problem could be there?

Probably.

> 
> Any other suggestion?

Just remember that -pg is very intrusive. I don't know your arch, nor
have I seen the code you did to update it. You can disable the -pg from
process.c by adding in the Makefile:

CFLAGS_REMOVE_process.o = -pg

And that will keep the process.c from being compiled with it. There may
be other files in the arch that should not have it. There's several in
x86 and in PowerPC.

-- Steve


--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ