From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19082 invoked by alias); 13 Jun 2013 15:08:51 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 19024 invoked by uid 89); 13 Jun 2013 15:08:44 -0000 X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 13 Jun 2013 15:08:44 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5DF8bZ0011328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 11:08:37 -0400 Received: from fche.csb (vpn-62-51.rdu2.redhat.com [10.10.62.51]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5DF8baK009243; Thu, 13 Jun 2013 11:08:37 -0400 Received: by fche.csb (Postfix, from userid 2569) id A9D1F58502; Thu, 13 Jun 2013 11:08:36 -0400 (EDT) To: Jia He Cc: systemtap@sourceware.org Subject: Re: [Patch RFC] Tolerate if nsrcs>1 in iterate_over_srcfile_lines References: From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 13 Jun 2013 15:08:00 -0000 In-Reply-To: (Jia He's message of "Thu, 13 Jun 2013 14:37:30 +0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2013-q2/txt/msg00277.txt.bz2 Jia He writes: > Now if dwarf_getsrc_file returns by nsrcs>1 in > dwflpp::iterate_over_srcfile_lines, > The loop for (int l = lineno; ; l = l + 1) will not be continued. > But actually it is not correct in some cases. Could you elaborate why you think it is incorrect? Some of the filtering is done deliberately, for example if the compiler debuginfo cannot give an unambiguous starting PC-address for a source-level statement. > --- systemtap-2.2.1.orig/dwflpp.cxx 2013-05-16 10:30:37.000000000 -0400 > +++ systemtap-2.2.1/dwflpp.cxx 2013-06-13 01:59:52.000000000 -0400 > @@ -1619,7 +1619,7 @@ dwflpp::iterate_over_srcfile_lines (char > if (line_type == RANGE && lineno > lines[1]) > break; > line_probed = lines_probed.insert(lineno); > - if (lineno != l || line_probed.second == false || nsrcs > 1) > + if (lineno != l || line_probed.second == false) > continue; > dwarf_lineaddr (srcsp [0], &line_addr); > if (!function_name_matches(func_pattern) && dwarf_haspc > (function, line_addr) != 1) For example, this change would ignore srcsp[n] for n>0, which would need an explanation about how that could come about and why we can ignore them. > advice << srcfile << ":" << hi_try; > advice << ")"; > } > - throw semantic_error (advice.str()); > + if (sess.verbose > 0) > + clog< +// throw semantic_error (advice.str()); > } What would be the purpose of this change? > test result > command:stap -L 'kernel.statement("sys_nanosleep@kernel/hrtimer.c:*")' > in X86_64) > Before this patch: > kernel.statement("sys_nanosleep@kernel/hrtimer.c:1612") $rmtp:struct > timespec* $tu:struct timespec > > After this patch: > kernel.statement("sys_nanosleep@kernel/hrtimer.c:1602") $rqtp:struct > timespec* $rmtp:struct timespec* $tu:struct timespec > kernel.statement("sys_nanosleep@kernel/hrtimer.c:1605") $rqtp:struct > timespec* $rmtp:struct timespec* $tu:struct timespec > kernel.statement("sys_nanosleep@kernel/hrtimer.c:1608") $rmtp:struct > timespec* $tu:struct timespec > kernel.statement("sys_nanosleep@kernel/hrtimer.c:1611") $rmtp:struct > timespec* $tu:struct timespec > kernel.statement("sys_nanosleep@kernel/hrtimer.c:1612") $rmtp:struct > timespec* $tu:struct timespec That looks good, as long as those listed probe points map to proper addresses and give back proper context variables. - FChE