Messages in this thread |  | | From | Namhyung Kim <> | Subject | Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6) | Date | Wed, 06 Nov 2013 17:31:00 +0900 |
| |
Hi Oleg,
On Tue, 5 Nov 2013 17:28:20 +0100, Oleg Nesterov wrote: > On 11/05, Namhyung Kim wrote: >> >> On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote: >> > Or the syntax should be "name=probe @file/addr" or something like this. >> >> Okay. Let's call this kind of thing "cross-fetch" (or a better name can >> be suggested). > > Yes ;) and I am afraid there was some confusion in our discussion. > I probably confused "probe other binaries" with cross-fetch and vice > versa sometimes.
Sorry for not being clear enough.
> >> > So far I think that trace_uprobes.c should not play games with vma. At all. >> >> Yes, playing with vma is fragile. But otherwise how can we get the >> address from the file+offset in random processes? > > Yes, this is not as simple as I thought. > > Let me repeat, somehow I completely forgot we need to probe other (libc) > binaries (not only the executable itself) and dump the data from that > binary. That is why I wrongly thought that that ->start_data trick can > work. > > OK, I see other emails from you. Perhaps we can rely on instruction_pointer(), > (I'll write more emails on this), But if not, then we probably need tu->inode > and vma games in fetch/get_user_vaddr(). I'd still like to avoid this, if > possible, but I am no longer sure.
Yes, I think it'll be necessary for the cross-fetch anyway.
Thanks, Namhyung
|  |