lkml.org 
[lkml]   [2012]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [QUESTION] Can uprobe_event support @ADDR, $retval, offs(FETCHARG)?
From
Hi,

2012/9/26 Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>:
> (2012/09/26 11:52), Hyeoncheol Lee wrote:
>> Hi,
>>
>> uprobe_event only supports %REG arguments. I think that memory fetch,
>> return value fetch, memory dereference functions in
>> kernel/trace/trace_probe.c are good for uprobe_event. So with a little
>> modification of parse_probe_arg(), uprobe_event can support @ADDR,
>> $retval, offs(FETCHARGS) except @SYM, $stack, $stackN. Is it right?
>
> Hi Hyeoncheol,
>
> Perhaps, it is not so small things, but at least, we can try.
> In the userspace, memories(pages) can be paged out on swap or
> files. In that case, memory dereference function needs to track
> down the data on the disk and it causes I/O. This means we will
> see the visible performance degradation with tracing.
> And also, sometime a pointer value (address) is broken, in that
> case we have to ensure the address is actually valid before
> accessing it.
>
> Of cause, without tracking paged-out data, it is easy
> to support, because that is already done in kprobe event.
> I'm not sure how it is useful, because sometimes it will
> fail to access gather the data.
> However it is good for the first step, I think.

Yes, we should consider paged-out data. I forgot this.

>
> Srikar, what would you think?
>
> BTW, if we can support offs(FETCHARGS), $stack and $stackN
> are also available. ;)

Yes, but we should check whether the given address is in an user stack
or not. and these require CPU architecture dependent codes.

>
> Thank you,
>
> --
> Masami HIRAMATSU
> Software Platform Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>

Thanks for your answer. It is very help to me. ;)

Hyeoncheol


\
 
 \ /
  Last update: 2012-09-26 09:21    [W:0.053 / U:1.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site