From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16914 invoked by alias); 16 Oct 2006 01:15:18 -0000 Received: (qmail 16905 invoked by uid 22791); 16 Oct 2006 01:15:17 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Oct 2006 01:15:14 +0000 Received: by ug-out-1314.google.com with SMTP id z36so673513uge for ; Sun, 15 Oct 2006 18:15:12 -0700 (PDT) Received: by 10.67.119.13 with SMTP id w13mr7379163ugm; Sun, 15 Oct 2006 18:15:12 -0700 (PDT) Received: by 10.67.99.11 with HTTP; Sun, 15 Oct 2006 18:15:09 -0700 (PDT) Message-ID: Date: Mon, 16 Oct 2006 01:15:00 -0000 From: s88 To: s88 , gdb@sourceware.org Subject: Re: gdb breakpoint on x86 In-Reply-To: <20061016003930.GA525@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061016003930.GA525@nevyn.them.org> 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-10/txt/msg00108.txt.bz2 On 10/16/06, Daniel Jacobowitz wrote: > On Mon, Oct 16, 2006 at 08:12:29AM +0800, s88 wrote: > > Hi all: > > I'm trying to build up a simple breakpoint insertor by myself. I also > > tracing the gdb source code and reference it!!! > > But I feel confused about the int 3(0xcc), the function > > "i386_breakpoint_from_pc" has 2 parameters, one of the parameter is a > > program counter. I'm not sure the meaning of this program counter. > > Does this program counter perform an ISR? Once the 0xcc trig, the > > current program counter will replace by this one? > > No, it's the address at which the breakpoint will be placed. On i386 > that doesn't matter, but on some other platforms it can affect which > instruction is used as a breakpoint. > > > By the way, the following code can compile without any error. But the > > sizeof which in the "i386_breakpoint_from_pc" derives segmentation > > fault. > > You need to read up on memory protection. You can't modify a running > program directly this way on most platforms. > Thank gor your reply... I have a new question, how to remove the memory protection? I'm trying to find out this part in gdb, but I do not find anything!! let's see the default_memory_insert_breakpoint (CORE_ADDR addr, bfd_byte *contents_cache) in the mem-break.c first, the program "determine appropriate breakpoint contents and size for this address". I don't know, the sizeof the int3 is 1 byte, right? why need to detect the "appropriate" breakpoint size? after determining the bp size, the program begin to save the target memory which will insert the 0xcc, then write the 0xcc into the indecate memory location. so, break up the memory protection is nessesary during the read/write memory part in the "default_memory_insert_breakpoint", right? 36 /* Insert a breakpoint on targets that don't have any better breakpoint 37 support. We read the contents of the target location and stash it, 38 then overwrite it with a breakpoint instruction. ADDR is the target 39 location in the target machine. CONTENTS_CACHE is a pointer to 40 memory allocated for saving the target contents. It is guaranteed 41 by the caller to be long enough to save BREAKPOINT_LEN bytes (this 42 is accomplished via BREAKPOINT_MAX). */ 43 44 int 45 default_memory_insert_breakpoint (CORE_ADDR addr, bfd_byte *contents_cache) 46 { 47 int val; 48 const unsigned char *bp; 49 int bplen; 50 51 /* Determine appropriate breakpoint contents and size for this address. */ 52 bp = BREAKPOINT_FROM_PC (&addr, &bplen); 53 if (bp == NULL) 54 error (_("Software breakpoints not implemented for this target.")); 55 56 /* Save the memory contents. */ 57 val = target_read_memory (addr, contents_cache, bplen); 58 59 /* Write the breakpoint. */ 60 if (val == 0) 61 val = target_write_memory (addr, bp, bplen); 62 63 return val; 64 } thanks. > -- > Daniel Jacobowitz > CodeSourcery > -- System on Chip Design Lab. Dept. of Computer Science and Information Engineering, National Chung Cheng University E-mail : s88.tw@acm.org