Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752372AbbEKGD4 (ORCPT ); Mon, 11 May 2015 02:03:56 -0400 Received: from mail4.hitachi.co.jp ([133.145.228.5]:38898 "EHLO mail4.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751435AbbEKGDy (ORCPT ); Mon, 11 May 2015 02:03:54 -0400 Message-ID: <55504642.1020301@hitachi.com> Date: Mon, 11 May 2015 15:03:46 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: He Kuang , a.p.zijlstra@chello.nl, acme@kernel.org, jolsa@kernel.org, mingo@redhat.com CC: wangnan0@huawei.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/3] perf probe: Add --range option to show variable location range References: <1431165306-106463-1-git-send-email-hekuang@huawei.com> <1431165306-106463-2-git-send-email-hekuang@huawei.com> <554ECEB9.2040209@hitachi.com> <5550127D.7020506@huawei.com> In-Reply-To: <5550127D.7020506@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4535 Lines: 101 On 2015/05/11 11:22, He Kuang wrote: > Hi, Masami > > On 2015/5/10 11:21, Masami Hiramatsu wrote: >> On 2015/05/09 18:55, He Kuang wrote: >>> It is not easy for users to get the accurate byte offset or the line >>> number where a local variable can be probed. With '--range' option, >>> local variables in scope of the probe point are showed with byte offset >>> range, and can be added according to this range information. >>> >>> For example, there are some variables in function >>> generic_perform_write(): >>> >>> >>> 0 ssize_t generic_perform_write(struct file *file, >>> 1 struct iov_iter *i, loff_t pos) >>> 2 { >>> 3 struct address_space *mapping = file->f_mapping; >>> 4 const struct address_space_operations *a_ops = mapping->a_ops; >>> ... >>> 42 status = a_ops->write_begin(file, mapping, pos, bytes, flags, >>> &page, &fsdata); >>> 44 if (unlikely(status < 0)) >>> >>> But we got failed when we try to probe the variable 'a_ops' at line 42 >>> or 44. >>> >>> $ perf probe --add 'generic_perform_write:42 a_ops' >>> Failed to find the location of a_ops at this address. >>> Perhaps, it has been optimized out. >>> >>> This is because source code do not match assembly, so a variable may not >>> be available in the sourcecode line where it presents. After this patch, >>> we can lookup the accurate byte offset range of a variable, 'INV' >>> indicates that this variable is not valid at the given point, but >>> available in scope: >>> >>> $ perf probe --vars 'generic_perform_write:42' --range >>> Available variables at generic_perform_write:42 >>> @ >>> [INV] ssize_t written @ >>> [INV] struct address_space_operations* a_ops @ >>> [VAL] (unknown_type) fsdata @ >>> [VAL] loff_t pos @ >>> [VAL] long int status @ >>> [VAL] long unsigned int bytes @ >>> [VAL] struct address_space* mapping @ >>> [VAL] struct iov_iter* i @ >>> [VAL] struct page* page @ >>> >> Thanks, this looks easier to understand :) >> >> [...] >>> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c >>> index dcca551..30a1a1b 100644 >>> --- a/tools/perf/util/probe-finder.c >>> +++ b/tools/perf/util/probe-finder.c >>> @@ -43,6 +43,9 @@ >>> /* Kprobe tracer basic type is up to u64 */ >>> #define MAX_BASIC_TYPE_BITS 64 >>> >>> +/* Variable location invalid at addr but valid in scope */ >>> +#define VARIABLE_LOCATION_INVALID_AT_ADDR -10000 >> Hmm, could you use -ERANGE instead of this? >> Other part is OK for me. >> >> Thank you! > > I've checked libdw, it never returns -ERANGE, but there is an > errno conflict in the function convert_variable_location itself: > > 268 regs = get_arch_regstr(regn); > 269 if (!regs) { > 270 /* This should be a bug in DWARF or this tool */ > 271 pr_warning("Mapping for the register number %u " > 272 "missing on this architecture.\n", regn); > 273 return -ERANGE; > 274 } > > So shell we change the above errno to -ENOENT or choose another > errno for current 'VARIABLE_LOCATION_INVALID_AT_ADDR', what's > your opinion? OK, above should be changed to -ENOTSUP, since it does not seem to come from an invalid range :) Thank you, -- Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: masami.hiramatsu.pt@hitachi.com -- 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/