From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: Anton Arapov <anton@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>,
Christoph Hellwig <hch@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Roland McGrath <roland@hack.frob.com>,
Thomas Gleixner <tglx@linutronix.de>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH v9 3.2 2/9] uprobes: handle breakpoint and signal step exception.
Date: Wed, 18 Jan 2012 16:17:49 +0530 [thread overview]
Message-ID: <20120118104749.GG15447@linux.vnet.ibm.com> (raw)
In-Reply-To: <201201180518.31407.vapier@gentoo.org>
> On Wednesday 18 January 2012 04:02:32 Srikar Dronamraju wrote:
> > > Can we use existing SET_IP() instead of set_instruction_pointer() ?
> >
> > Oleg had already commented about this in one his uprobes reviews.
> >
> > The GET_IP/SET_IP available in include/asm-generic/ptrace.h doesnt work
> > on all archs. Atleast it doesnt work on powerpc when I tried it.
>
> so migrate the arches you need over to it.
One question that could be asked is why arent we using instruction_pointer
instead of GET_IP since instruction_pointer is being defined in 25
places and with references in 120 places.
>
> > Also most archs define instruction_pointer(). So I thought (rather Peter
> > Zijlstra suggested the name set_instruction_pointer())
> > set_instruction_pointer was a better bet than SET_IP. I
>
> asm-generic/ptrace.h already has instruction_pointer_set()
>
> > Also I dont see any usage for SET_IP/GET_IP.
>
> i think you mean "users" here ? the usage should be fairly obvious. both
> macros are used by asm-generic/ptrace.h internally, but (currently) rarely
> defined by arches themselves (by design). the funcs that are based on these
> GET/SET helpers though do get used in many places.
>
> simply grep arch/*/include/asm/ptrace.h
here are the stats
$ grep -r -w GET_IP * | wc -l
5
$ grep -r -w SET_IP * | wc -l
3
$ grep -r -w instruction_pointer * | wc -l
120
$ grep -r -w instruction_pointer_set * | wc -l
3
The only place I saw GET_IP was used was to define SET_IP
The only place I saw SET_IP was used was to define
instruction_pointer_set.
The only place I saw instruction_pointer_set being used is drivers/misc/kgdbts.c
instruction_pointer was defined in close to 25 places.
>
> > May be we should have something like this in
> > include/asm-generic/ptrace.h
> >
> > #ifdef instruction_pointer
> > #define GET_IP(regs) (instruction_pointer(regs))
> > #define set_instruction_pointer(regs, val) (instruction_pointer(regs) =
> > (val))
> > #define SET_IP(regs, val) (set_instruction_pointer(regs,val))
> > #endif
> >
>
> what you propose here won't work on all arches which is the whole point of
> {G,S}ET_IP in the first place. i proposed a similar idea before and was shot
> down for exactly that reason. look at ia64 for an obvious example.
Sorry, I didnt quite understand this.
Was it that people objected to instruction_pointer or
Is it that instruction_pointer and GET_IP will work differently on few
architectures or
Is it people had an objection to defining instruction_pointer.
So let me rephrase here. Initially we used set_ip. But Peter suggested
that the name be changed to set_instruction_pointer so that it goes with
instruction_pointer. I also felt that set_instruction_pointer was
better. However I am okay with any other name including
SET_IP/instruction_pointer_set. I have no issues in moving the
set_instruction_pointer to arch/*/ptrace.h files it it helps (including
include/asm-generic/ptrace.h).
But I think we should either have GET_IP or instruction_pointer.
Similarly either SET_IP/set_instruction_pointer{_set}. Since
instruction_pointer is more widely used, I would side by the
instruction_pointer.
>
> > or should we do away with GET_IP/SET_IP esp since there are no many
> > users?
>
> no, the point is to migrate to asm-generic/ptrace.h, not away from it.
I think the rational for having asm-generic/ptrace.h was to have define
a way to get the instruction_pointer such that the each archs dont have
to define their own definition unless and untill its necessary.
If yes, then why did we choose the names GET_IP/SET_IP instead of
instruction_pointer and the like.
--
Thanks and Regards
Srikar
next prev parent reply other threads:[~2012-01-18 10:57 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 11:48 [PATCH v9 3.2 0/9] Uprobes patchset with perf probe support Srikar Dronamraju
2012-01-10 11:48 ` [PATCH v9 3.2 1/9] uprobes: Install and remove breakpoints Srikar Dronamraju
2012-01-25 14:39 ` Denys Vlasenko
2012-01-25 16:31 ` Oleg Nesterov
2012-01-25 15:13 ` Denys Vlasenko
2012-01-25 15:32 ` Denys Vlasenko
2012-01-26 14:14 ` Masami Hiramatsu
2012-01-26 18:28 ` Denys Vlasenko
2012-01-30 9:51 ` Masami Hiramatsu
2012-01-26 13:38 ` Masami Hiramatsu
2012-01-26 13:45 ` Masami Hiramatsu
2012-01-10 11:48 ` [PATCH v9 3.2 2/9] uprobes: handle breakpoint and signal step exception Srikar Dronamraju
2012-01-18 8:39 ` Anton Arapov
2012-01-18 9:02 ` Srikar Dronamraju
2012-01-18 10:18 ` Mike Frysinger
2012-01-18 10:47 ` Srikar Dronamraju [this message]
2012-01-18 11:01 ` Mike Frysinger
2012-01-20 22:57 ` Mike Frysinger
2012-01-25 8:12 ` Srikar Dronamraju
2012-01-10 11:48 ` [PATCH v9 3.2 3/9] uprobes: slot allocation Srikar Dronamraju
2012-01-10 11:49 ` [PATCH v9 3.2 4/9] uprobes: counter to optimize probe hits Srikar Dronamraju
2012-01-10 11:49 ` [PATCH v9 3.2 5/9] tracing: modify is_delete, is_return from ints to bool Srikar Dronamraju
2012-01-10 11:49 ` [PATCH v9 3.2 6/9] tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2012-01-10 11:49 ` [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface Srikar Dronamraju
2012-01-16 13:11 ` Jiri Olsa
2012-01-16 14:45 ` Srikar Dronamraju
2012-01-16 15:33 ` Jiri Olsa
2012-01-16 16:41 ` Srikar Dronamraju
2012-01-17 9:28 ` Ingo Molnar
2012-01-17 10:22 ` Srikar Dronamraju
2012-01-17 10:59 ` Ingo Molnar
2012-01-17 11:03 ` Srikar Dronamraju
2012-01-17 11:22 ` Ingo Molnar
2012-01-17 11:57 ` Srikar Dronamraju
2012-01-17 12:23 ` Ingo Molnar
2012-01-17 12:27 ` Ingo Molnar
2012-01-17 12:11 ` Ingo Molnar
2012-01-17 12:21 ` Ingo Molnar
2012-01-18 10:07 ` Srikar Dronamraju
2012-01-10 11:49 ` [PATCH v9 3.2 8/9] perf: rename target_module to target Srikar Dronamraju
2012-01-16 8:34 ` [PATCH v9 3.2 0/9] Uprobes patchset with perf probe support Ingo Molnar
2012-01-16 15:17 ` Srikar Dronamraju
2012-01-17 9:39 ` Ingo Molnar
2012-01-25 14:11 ` Peter Zijlstra
2012-01-26 11:10 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120118104749.GG15447@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=andi@firstfloor.org \
--cc=anton@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=roland@hack.frob.com \
--cc=rostedt@goodmis.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).