On Tue, Aug 21, 2012 at 03:09:30PM +0200, Oleg Nesterov wrote:
...
> > This is true for Intel like architectures that have *one* swbp
> > instruction. On Powerpc, gdb for instance, can insert a trap variant at
> > the address. Therefore, is_swbp_insn() by definition should return true
> > for
On Tue, Aug 21, 2012 at 03:09:30PM +0200, Oleg Nesterov wrote:
...
This is true for Intel like architectures that have *one* swbp
instruction. On Powerpc, gdb for instance, can insert a trap variant at
the address. Therefore, is_swbp_insn() by definition should return true
for all trap
On 08/21, Ananth N Mavinakayanahalli wrote:
>
> On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
>
> > > We should also take
> > > care of the in-memory copy, in case gdb had inserted a breakpoint at the
> > > same location, right?
> >
> > gdb (or even the application itself) and
On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
> On 08/17, Ananth N Mavinakayanahalli wrote:
> >
> > On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
> >
> > > Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
> > > code, should only return
On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
On 08/17, Ananth N Mavinakayanahalli wrote:
On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
code, should only return true if insn ==
On 08/21, Ananth N Mavinakayanahalli wrote:
On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
We should also take
care of the in-memory copy, in case gdb had inserted a breakpoint at the
same location, right?
gdb (or even the application itself) and uprobes can
On 08/17, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
>
> > Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
> > code, should only return true if insn == UPROBE_SWBP_INSN (just in case,
> > this logic needs more
On 08/17, Ananth N Mavinakayanahalli wrote:
On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
code, should only return true if insn == UPROBE_SWBP_INSN (just in case,
this logic needs more fixes but
On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
...
> > So, the arch agnostic code itself
> > takes care of this case...
>
> Yes. I forgot about install_breakpoint()->is_swbp_insn() check which
> returns -ENOTSUPP, somehow I thought arch_uprobe_analyze_insn() does
> this.
>
> >
On 08/16, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> > > On 07/26, Ananth N Mavinakayanahalli wrote:
> > > >
> > > > From: Ananth N Mavinakayanahalli
> > > >
> > > >
On 08/16, Ananth N Mavinakayanahalli wrote:
On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
On 07/26, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is
On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
...
So, the arch agnostic code itself
takes care of this case...
Yes. I forgot about install_breakpoint()-is_swbp_insn() check which
returns -ENOTSUPP, somehow I thought arch_uprobe_analyze_insn() does
this.
or am I
On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> > On 07/26, Ananth N Mavinakayanahalli wrote:
> > >
> > > From: Ananth N Mavinakayanahalli
> > >
> > > This is the port of uprobes to powerpc. Usage is similar to
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> On 07/26, Ananth N Mavinakayanahalli wrote:
> >
> > From: Ananth N Mavinakayanahalli
> >
> > This is the port of uprobes to powerpc. Usage is similar to x86.
>
> I am just curious why this series was ignored by powerpc maintainers...
On 07/26, Ananth N Mavinakayanahalli wrote:
>
> From: Ananth N Mavinakayanahalli
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
I am just curious why this series was ignored by powerpc maintainers...
Of course I can not review this code, I know nothing about powerpc,
but
On 07/26, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to x86.
I am just curious why this series was ignored by powerpc maintainers...
Of course I can not review this code, I know nothing about
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
On 07/26, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to x86.
I am just curious why this series was ignored by powerpc
On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
On 07/26, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to
* Ananth N Mavinakayanahalli [2012-07-26 10:50:29]:
> From: Ananth N Mavinakayanahalli
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
>
> [root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
> Added new event:
> probe_libc:malloc(on 0xb4860)
>
> You can now
* Ananth N Mavinakayanahalli ana...@in.ibm.com [2012-07-26 10:50:29]:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to x86.
[root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
Added new event:
probe_libc:malloc(on
From: Ananth N Mavinakayanahalli
This is the port of uprobes to powerpc. Usage is similar to x86.
[root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
Added new event:
probe_libc:malloc(on 0xb4860)
You can now use it in all perf tools, such as:
perf record -e
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to x86.
[root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
Added new event:
probe_libc:malloc(on 0xb4860)
You can now use it in all perf tools, such as:
perf record
22 matches
Mail list logo
