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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101221173637.GN1750@nowhere>
Date:	Tue, 21 Dec 2010 18:36:39 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Akihiro Nagai <akihiro.nagai.hw@...achi.com>
Cc:	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	"akihiro.nagai.hw@...achi.com"@sdl.hitachi.co.jp,
	Paul Mackerras <paulus@...ba.org>,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	2nddept-manager@....hitachi.co.jp
Subject: Re: [PATCH -tip v2 0/6] perf: Introduce bts sub commands

On Tue, Dec 21, 2010 at 06:05:27PM +0900, Akihiro Nagai wrote:
> Hi,
> 
> This patch series provides the commands 'perf bts record' and 'perf bts trace'
> version 2. These commands can record and analyze BTS (Branch Trace Store) log.
> And, provide the interface to use BTS log for application developers.
> 
> BTS is a facility of Intel x86 processors, which can record the address of
> 'branch to/from' on every branch/jump instruction and interrupt.
> This facility is very useful for developers to test their software.
> For example, coverage test, execution path analysis, dynamic step count ...etc.
> Also, those tools can have a very big advantage that they don't require any
> changes of the target executable binaries.
> 
> But, there are few applications using BTS. Reasons I guess are ...
>  - Few people know what BTS is.
>  - Few people know how to use BTS on Linux box.
>  - It's hard to analyze the BTS log because it includes just a series of addresses.

And I would add:

- It has a big overhead, probably because the CPU spends some time to record
the branches, but also because it generates a huge amount of traces to save
periodically.

- It seems it's only available on intel CPUs (and some of them)

- It can't do branch type filtering like LBR does on some intel CPUs.
  Like recording only call and ret branches and ignore jmp, je, etc...
  which would make lower overhead if our goal is to trace only the function
  graph for example.

OTOH it has a great potential.

> 
> So, I want to provide a user-friendly interface to BTS for application developers.
> 
> 
>  About new sub commands
> ========================
> 'perf bts record' provides the easy way to record bts log.

I would suggest to call it perf branch. Bts beeing only an
underlying backend feature that makes it working. An implementation
detail. For example, the function graph traces may join in the
future to provide some branch details of the kernel, only in
the function level of course.

> Usage is 'perf bts record <command>'.  This command is just an alias to
> 'perf record -e branches:u -c 1 <command>'. But, new one is more simple and
> more intuitive.
> 
> 'perf bts trace' can parse and analyze recorded bts log and print various
> information of execution path. This command can show address, pid, command name,
> function+offset, file path of elf.
> You can choose the printed information with option.
> 
> Example: 'perf bts trace'
> function+offset
> irq_return+0x0  => _start+0x0
> irq_return+0x0  => _start+0x0
> _start+0x3      => _dl_start+0x0
> irq_return+0x0  => _dl_start+0x0
> irq_return+0x0  => _dl_start+0x26
> irq_return+0x0  => _dl_start+0x2d
> _dl_start+0x71  => _dl_start+0x93
> _dl_start+0x97  => _dl_start+0x78
> ...
> 
> This is the default behavior of 'perf bts trace'. It prints function+offset.

That's a good start!

I suspect in the future, the default should be a function graph layout
and only dive into in-proc branch details if requested by means of
options.

But may be I'm biaised and in practice we need to output the branches
right away. That said I suspect a function graph should give the first desired
overview.

This can probably be done incrementally though, this output is already a
nice feature.


> Example2: 'perf bts -cas trace'
> command address            function+offset                  
> ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806200b20 _start+0x0
> ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806200b20 _start+0x0
> ls      0x0000003806200b23 _start+0x3      => ls   0x0000003806204910 _dl_start+0x0
> ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806204910 _dl_start+0x0
> ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806204936 _dl_start+0x26
> ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x000000380620493d _dl_start+0x2d
> ls      0x0000003806204981 _dl_start+0x71  => ls   0x00000038062049a3 _dl_start+0x93
> ls      0x00000038062049a7 _dl_start+0x97  => ls   0x0000003806204988 _dl_start+0x78

Cool!

> ...
> 
> In the future, I'd like to make this more informative. For example
>  - Show source file path
>  - Show line number
>  - Show inlined function name
>  - Draw call graph
>  - Browse source code and coloring
>  - Make bts record fast
> and more!

Very nice plans.

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