linux-kernel - Re: [RFC/PATCH] perf tools: Introduce perf

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] [day] [month] [year] [list]

Date:	Tue, 24 Nov 2015 16:36:03 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
CC:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace

Hi Jiri,

On Fri, Nov 20, 2015 at 10:29:48AM +0100, Jiri Olsa wrote:
> On Fri, Nov 20, 2015 at 03:03:03PM +0900, Namhyung Kim wrote:
> > Backtrace is a crucial info for debugging.  And upcoming refcnt
> > tracking facility also wants to use it.
> > 
> > So instead of relying on glibc's backtrace_symbols[_fd] which misses
> > some (static) functions , use our own symbol searching mechanism.  To
> > do that, add perf_thread global variable to keep its maps and symbols.
> > 
> > The backtrace output from TUI is changed like below.  (I made a key
> > action to generate a segfault for testing):
> > 
> > Before:
> >   perf: Segmentation fault
> >   -------- backtrace --------
> >   perf[0x544a8b]
> >   /usr/lib/libc.so.6(+0x33680)[0x7fc46420b680]
> >   perf[0x54041b]
> >   perf(perf_evlist__tui_browse_hists+0x91)[0x5432e1]
> >   perf(cmd_report+0x1d20)[0x43cb10]
> >   perf[0x487073]
> >   perf(main+0x62f)[0x42cb1f]
> >   /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fc4641f8610]
> >   perf(_start+0x29)[0x42cc39]
> >   [0x0]
> > 
> > After:
> >   perf: Segmentation fault
> >   -------- backtrace --------
> >   perf_evsel__hists_browse(+0x43b) in perf [0x54066b]
> >   perf_evlist__tui_browse_hists(+0x91) in perf [0x543531]
> >   cmd_report(+0x1d20) in perf [0x43cb50]
> >   run_builtin(+0x53) in perf [0x4870b3]
> >   main(+0x634) in perf [0x42cb54]
> >   __libc_start_main(+0xf0) in libc-2.22.so [0x7fea3577c610]
> >   _start(+0x29) in perf [0x42cc79]
> >   [0x0]
> 
> nice idea! 
> 
> SNIP
> 
> > +
> > +void create_perf_thread(void)
> > +{
> > +	struct perf_tool tool = {
> > +		.comm	= perf_event__process_comm,
> > +		.mmap	= perf_event__process_mmap,
> > +		.mmap2	= perf_event__process_mmap2,
> > +	};
> > +	struct thread_map *tm;
> > +	struct machine *machine;
> > +	int pid = getpid();
> > +
> > +	machine = machine__new_host();
> > +	if (machine == NULL)
> > +		return;
> > +
> > +	tm = thread_map__new_dummy();
> > +	if (tm == NULL) {
> > +		machine__delete(machine);
> > +		return;
> > +	}
> 
> I think we could treat errors the usual way in here..
> if fail to alloc this early, something is terribly wrong anyway

OK, I'll change it to return error code and let perf fail with it.

Thanks,
Namhyung
--
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/