From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10298 invoked by alias); 2 Feb 2006 04:45:06 -0000 Received: (qmail 10288 invoked by uid 22791); 2 Feb 2006 04:45:05 -0000 X-Spam-Check-By: sourceware.org Received: from mailsrv1.tranzpeer.net (HELO mailsrv1.tranzpeer.net) (202.180.66.207) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Feb 2006 04:45:03 +0000 Received: from wmsrv2.tranzpeer.net ([202.180.66.2] helo=localhost) by mailsrv1.tranzpeer.net with ESMTP (Exim 4.34) id 1F4WL5-0001wO-6P; Thu, 02 Feb 2006 17:45:00 +1300 Received: from external.hosting.co.nz (external.hosting.co.nz [203.97.46.10]) by webmail.slingshot.co.nz (Horde) with HTTP for ; Thu, 2 Feb 2006 17:45:00 +1300 Message-ID: <20060202174500.8gcgws4wk04kwgs0@webmail.slingshot.co.nz> Date: Thu, 02 Feb 2006 04:45:00 -0000 From: Paul Blacquiere To: Daniel Jacobowitz Cc: "gdb@sourceware.org" Subject: Re: Howto single step from beginning References: <20060202140831.wco48wcskkccsokk@webmail.slingshot.co.nz> <20060202012556.GA19090@nevyn.them.org> <20060202155252.k84sosswgkwkwsg4@webmail.slingshot.co.nz> <20060202025704.GA21125@nevyn.them.org> In-Reply-To: <20060202025704.GA21125@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00008.txt.bz2 > Check with "set debug target 1" before running to see > what bytes it's inserting, then check your kernel sources (esp. > arm/kernel/ptrace.c and arm/kernel/traps.c) to see which breakpoints > it expects. Ok, not sure how to interpret this: ------------------------------------ (gdb) run Starting program: /home/blacq/src/bin/test target_acknowledge_created_inferior (198) . . . child:target_xfer_partial (2, (null), 0x1fc248, 0x0, 0x8094, 4) = 4, bytes = 00 e0 a0 e3 child:target_xfer_partial (2, (null), 0x0, 0x18c436, 0x8094, 4) = 4, bytes = fe de ff e7 target_insert_breakpoint (0x8094, xxx) = 0 ------------------------------------ So the first xfer, I assume retrieved the command at 0x08094, which is as per the objdump. the second xfer writes a 0x0e7ffdefe to 0x08094, which is an undefined command. Is my interpretation correct? From ptrace.c I find a comment as follows: --- /* * New breakpoints - use an undefined instruction. The ARM architecture * reference manual guarantees that the following instruction space * will produce an undefined instruction exception on all CPUs: * * ARM: xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx * Thumb: 1101 1110 xxxx xxxx */ #define BREAKINST_ARM 0xe7f001f0 #define BREAKINST_THUMB 0xde01 --- If my interpretation on the gdb trace is correct, then it seems gdb is writing an undefined instruction to generate an exception, but not the correct "user instruction" to catch the registered hook? But this part I am guessing. Thanks PaulB.