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:48:54 +0900 |
| |
On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote: > On 11/05, Namhyung Kim wrote: >> >> This is what I have for now: >> >> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr, >> struct trace_uprobe *tu) >> { >> unsigned long base_addr; >> unsigned long vaddr; >> >> base_addr = instruction_pointer(regs) - tu->offset; >> vaddr = base_addr + addr; >> >> return (void __force __user *) vaddr; >> } >> >> When I tested it, it was able to fetch global and bss data from both of >> executable and library properly. > > Heh ;) I didn't expect you will agree with this suggestion. But if you > think it can work - great!
It seems to work for me well except the cross-fetch.
But I'm not sure it'll work for every cases. It would be great if some elf gurus come up and give some feedbacks.
Masami?
> > Let me clarify just in case. Yes, _personally_ I think we should try > to avoid the vma games, and it looks better to me this way. But I won't > argue if you change your mind, I understand this approach has its own > disadvantages. > > As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate > the "@" argument anyway, why it can't also substruct this offset?
Hmm.. it makes sense too. :)
> > Or perhaps we can change parse_probe_arg("@") to update "param" ? Yes, > in this case it needs another argument, not sure... > >> But it still doesn't work for uretprobes >> as you said before. > > This looks simple, > > + if (is_ret_probe(tu)) { > + saved_ip = instruction_pointer(regs); > + instruction_pointer_set(func); > + } > store_trace_args(...); > + if (is_ret_probe(tu)) > + instruction_pointer_set(saved_ip); > > although not pretty.
So for normal non-uretprobes, func == instruction_pointer(), right?
If so, just passing func as you suggested looks better than this.
Thanks, Namhyung
|  |