From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25742 invoked by alias); 24 Aug 2010 20:34:53 -0000 Received: (qmail 25732 invoked by uid 22791); 24 Aug 2010 20:34:52 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_TM,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Aug 2010 20:34:44 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7OKYhqr032002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Aug 2010 16:34:43 -0400 Received: from [10.3.113.78] (ovpn-113-78.phx2.redhat.com [10.3.113.78]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7OKYhx7031721; Tue, 24 Aug 2010 16:34:43 -0400 Message-ID: <4C742CE2.7070408@redhat.com> Date: Tue, 24 Aug 2010 20:34:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2 MIME-Version: 1.0 To: Roland McGrath CC: systemtap@sources.redhat.com Subject: Re: semantic error: multiple addresses for ... References: <20100820203946.0169540144@magilla.sf.frob.com> <4C742200.7000401@redhat.com> <20100824195519.9C0D74048C@magilla.sf.frob.com> In-Reply-To: <20100824195519.9C0D74048C@magilla.sf.frob.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2010-q3/txt/msg00290.txt.bz2 On 08/24/2010 12:55 PM, Roland McGrath wrote: > Off hand, I see two potential approaches: > > 1. Pay attention to is_stmt. > I mentioned this earlier. To consider this, we'd really need to find > some cases where the current code legitimately complains as in PR1306, > and check whether the is_stmt flags in that DWARF info are useful. I'm not sure how to check is_stmt, but here's a reproducer at a similar location to the original bug report. kernel-2.6.33.8-149.fc13.x86_64 fs/open.c: > 1047 long do_sys_open(int dfd, const char __user *filename, int flags, int mode) > 1048 { > 1049 char *tmp = getname(filename); > 1050 int fd = PTR_ERR(tmp); > 1051 > 1052 if (!IS_ERR(tmp)) { > 1053 fd = get_unused_fd_flags(flags); > 1054 if (fd >= 0) { > 1055 struct file *f = do_filp_open(dfd, tmp, flags, mode, 0); > 1056 if (IS_ERR(f)) { > 1057 put_unused_fd(fd); > 1058 fd = PTR_ERR(f); > 1059 } else { > 1060 fsnotify_open(f->f_path.dentry); > 1061 fd_install(fd, f); > 1062 } > 1063 } > 1064 putname(tmp); > 1065 } > 1066 return fd; > 1067 } $ stap -L 'kernel.statement("do_sys_open@fs/open.c:1053")' semantic error: multiple addresses for fs/open.c:1053 (try fs/open.c:1051 or fs/open.c:1058) > 2. Apply the current rule only when there are multiple hits in the same scope. > This seems probably safer than relying on is_stmt, though it's not clear. > This should fix the case I just reported, and ones like it, where the > multiple hits are in entirely different instances of the same source code. Isn't it possible for a line to legitimately occur multiple times in the same scope? For example, a statement within an unrolled loop *should* get multiple probes after all, right? The funny thing is that the current rule is only applied for statement probes on line numbers (see the use of need_single_match). Function probes with line numbers are allowed to have duplicates, probably for the exact reason you're complaining about, that there may be multiple inline instances. Josh