Re: [PATCH 3/3] perf probe: Add --range option to show variable location range

[Masami Hiramatsu]

On 2015/05/09 16:41, He Kuang wrote:
> 
> On 2015/5/8 22:08, Masami Hiramatsu wrote:
>> On 2015/05/08 21:23, 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.
>> Interesting idea :)
>>
>>> For example, there are some variables in function
>>> generic_perform_write():
>>>
>>>    <generic_perform_write@mm/filemap.c:0>
>>>    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.
>> Yeah, right. That's why I've introduced --vars option.
>>
>>> 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
>>>          @<generic_perform_write+141>
>>>                  [INV]   ssize_t written [byte offset]: <324-331>
>>>                  [INV]   struct address_space_operations*        a_ops   [byte offset]: <55-61>,<170-176>,<223-246>
>>>                  [VAL]   (unknown_type)  fsdata  [byte offset]: <70-307>,<346-411>
>>>                  [VAL]   loff_t  pos     [byte offset]: <0-286>,<286-336>,<346-411>
>>>                  [VAL]   long int        status  [byte offset]: <83-342>,<346-411>
>>>                  [VAL]   long unsigned int       bytes   [byte offset]: <122-311>,<320-338>,<346-403>,<403-411>
>>>                  [VAL]   struct address_space*   mapping [byte offset]: <35-344>,<346-411>
>>>                  [VAL]   struct iov_iter*        i       [byte offset]: <0-340>,<346-411>
>>>                  [VAL]   struct page*    page    [byte offset]: <70-307>,<346-411>
>> OK, at first, I don't like frequently repeated "[byte offset]", I prefer to
>> show the function name+[offset range], like below :)
>>
>>   [INV]   ssize_t written @<generic_perform_write+[324-331]>
>>   [INV]   struct address_space_operations*        a_ops   <@generic_perform_write+[55-61,170-176,223-246]>
> 
> OK.
> 
>>
>> By the way, 'generic_perform_write+170' may be different from
>> given line, is that OK?
> 
> I think the prefix '[INV]' indicates that difference.
> 
> Before this patch, we should reference objdump, dwarf-info, then
> dwarf-loc to find the valid range of a variable. Sometimes we
> want to view more than one variables by adding one probe event,
> to find a place two or more variables all valid is difficult.

Yes, I think this looks good idea to trace variables :)

> 
> This patch gives an overview of the valid ranges of variables in
> scope, in most case, if we just want to find a place to probe
> variables, the location range result is just enough.  And we can
> use the result offset to locate the assembly code of the accurate
> meaning of a variable from objdump easily.

OK, but please note that the optimizer sometimes arranges code
sequence different from the source code. So I recommend to ensure
the address is actually where you imagine, by using perf probe -l :)

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@xxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/