This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch RFC] Tolerate if nsrcs>1 in iterate_over_srcfile_lines


Jia He <hejianet@gmail.com> 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<<advice.str();
> +//          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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]