Date: Fri, 20 Nov 2015 10:29:48 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        LKML <linux-kernel@vger.kernel.org>, David Ahern <dsahern@gmail.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace
Message-ID: <20151120092948.GB897@krava.brq.redhat.com>
References: <1447999383-15456-1-git-send-email-namhyung@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1447999383-15456-1-git-send-email-namhyung@kernel.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2192
Lines: 72

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

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/