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

From: Masami Hiramatsu
Date: Sat May 09 2015 - 23:02:45 EST

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,

Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at