From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp06.in.ibm.com (e28smtp06.in.ibm.com [122.248.162.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e28smtp06.in.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 5E9C7B7D97 for ; Mon, 7 Jun 2010 17:03:58 +1000 (EST) Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by e28smtp06.in.ibm.com (8.14.4/8.13.1) with ESMTP id o5773rnw021813 for ; Mon, 7 Jun 2010 12:33:53 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5773rlM2728084 for ; Mon, 7 Jun 2010 12:33:54 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5773qei015616 for ; Mon, 7 Jun 2010 12:33:53 +0530 Date: Mon, 7 Jun 2010 12:33:51 +0530 From: "K.Prasad" To: Paul Mackerras Subject: Re: [Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXII Message-ID: <20100607070351.GA3853@in.ibm.com> References: <20100528063924.GA8679@in.ibm.com> <20100602113316.GA17061@brick.ozlabs.ibm.com> <20100604065145.GA2408@in.ibm.com> <20100604090648.GC26154@brick.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20100604090648.GC26154@brick.ozlabs.ibm.com> Cc: "linuxppc-dev@ozlabs.org" , Benjamin Herrenschmidt Reply-To: prasad@linux.vnet.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Jun 04, 2010 at 07:06:48PM +1000, Paul Mackerras wrote: > On Fri, Jun 04, 2010 at 12:21:45PM +0530, K.Prasad wrote: > > > Meanwhile I tested the per-cpu breakpoints with the new emulate_step > > patch (refer linuxppc-dev message-id: > > 20100602112903.GB30149@brick.ozlabs.ibm.com) and they continue to fail > > due to emulate_step() failure, in my case, on a "lwz r0,0(r28)" > > instruction. > > Strange, what was in r28? The emulator should handle that instruction. > It must be containing one of the offsets of "struct tracer" which is a parameter to the function trace_selftest_startup_ksym(). Basically this function does a selftest over hw-breakpoints by placing read-write breakpoint on a dummy global-variable and performs read-write access thereupon. The lwz instruction which fails here corresponds to the instruction that does read-write. A complete disassemble of the function upto the failing instruction (at address) is pasted at the end of this mail. > > About the latest patchset, given that we chose to ignore extraneous > > interrupts for non-ptrace breakpoints, I thought that re-using > > current->thread.ptrace_bps as a flag would be efficient than > > introducing > > a new member in 'struct thread_struct' to do the same. I'm not sure > > if > > you foresee any issues with that. > > I just wonder what provides exclusion between its use as a flag and > its use to hold a real ptrace breakpoint. As far as I can see nothing > does. If there is something, it's off in some other source file, > unless I'm missing something. And in that case there should be a bit > fat comment explaining why it's safe. > The hw_breakpoint_handler() goes like this: int __kprobes hw_breakpoint_handler(struct die_args *args) { ... .... /* * Return early after invoking user-callback function without restoring * DABR if the breakpoint is from ptrace which always operates in * one-shot mode. The ptrace-ed process will receive the SIGTRAP signal * generated in do_dabr(). */ if (is_ptrace_bp) { perf_bp_event(bp, regs); rc = NOTIFY_DONE; goto out; } /* * Verify if dar lies within the address range occupied by the symbol * being watched to filter extraneous exceptions. */ if (!((bp->attr.bp_addr <= dar) && (dar <= (bp->attr.bp_addr + bp->attr.bp_len)))) { /* * This exception is triggered not because of a memory access * on the monitored variable but in the double-word address * range in which it is contained. We will consume this * exception, considering it as 'noise'. */ is_extraneous_interrupt = true; } .... ... } Given that 'ptrace_bps' is used only for ptrace originated breakpoints and that we return early i.e. before detecting extraneous interrupts in hw_breakpoint_handler() (as shown above) they shouldn't overlap each other. The following comment in hw_breakpoint_handler() explains the same. /* * To prevent invocation of perf_event_bp(), we shall overload * thread.ptrace_bps[] pointer (unused for non-ptrace * exceptions) to flag an extraneous interrupt which must be * skipped. */ Thanks, K.Prasad (gdb) disass trace_selftest_startup_ksym Dump of assembler code for function trace_selftest_startup_ksym: 0xc000000000125580 : mflr r0 0xc000000000125584 : std r26,-48(r1) 0xc000000000125588 : std r27,-40(r1) 0xc00000000012558c : std r28,-32(r1) 0xc000000000125590 : std r29,-24(r1) 0xc000000000125594 : std r30,-16(r1) 0xc000000000125598 : std r31,-8(r1) 0xc00000000012559c : std r0,16(r1) 0xc0000000001255a0 : stdu r1,-176(r1) 0xc0000000001255a4 : mr r31,r1 0xc0000000001255a8 : ld r30,-17784(r2) 0xc0000000001255ac : mr r26,r4 0xc0000000001255b0 : mr r27,r3 0xc0000000001255b4 : bl 0xc000000000125510 0xc0000000001255b8 : li r4,3 0xc0000000001255bc : mr. r29,r3 0xc0000000001255c0 : mr r5,r29 0xc0000000001255c4 : beq 0xc0000000001255e0 0xc0000000001255c8 : ld r3,-31520(r30) 0xc0000000001255cc : ld r4,0(r27) 0xc0000000001255d0 : bl 0xc00000000009c560 0xc0000000001255d4 : nop 0xc0000000001255d8 : b 0xc000000000125690 0xc0000000001255dc : nop 0xc0000000001255e0 : ld r28,-31512(r30) 0xc0000000001255e4 : ld r3,-31504(r30) 0xc0000000001255e8 : stw r29,0(r28) 0xc0000000001255ec : mr r5,r28 0xc0000000001255f0 : bl 0xc000000000140760 0xc0000000001255f4 : nop 0xc0000000001255f8 : cmpwi cr7,r3,0 0xc0000000001255fc : mr r29,r3 0xc000000000125600 : blt cr7,0xc00000000012567c 0xc000000000125604 : lwz r0,0(r28) 0xc000000000125608 : cmpwi cr7,r0,0 0xc00000000012560c : bne cr7,0xc000000000125618 0xc000000000125610 : li r0,1