Re: semantic error: multiple addresses for ...

[Josh Stone <jistone@redhat.com>]

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