gdb breakpoint on x86

gdb breakpoint on x86

[s88]

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?

By the way, the following code can compile without any error. But the
sizeof which in the "i386_breakpoint_from_pc"  derives segmentation
fault.

Could anyone help me?!
Thanks.

#include <stdlib.h>
#include <stdio.h>

typedef int (*_test) (int, int);

typedef unsigned char my_byte;
typedef unsigned long CORE_ADDR;

static const my_byte *i386_breakpoint_from_pc (CORE_ADDR * pc, int *len);


/**
 * My test function
 */
int my_test (int a, int b){
 int i;
 int ret;
 for (i = 0; i < a; i++)
  {
    ret = a + 1 << b;
  }
 return ret;
}

void test (_test t){
 int *len=0;
 my_byte *b=NULL;
 printf("len = %d",len);
 b = (my_byte *)i386_breakpoint_from_pc ((CORE_ADDR *)(t), len);
 printf("len = %d",len);
}

static const my_byte *i386_breakpoint_from_pc (CORE_ADDR * pc, int *len){
 static my_byte break_insn[] = { 0xcc };       /* int 3 */
 *len = sizeof (break_insn);
 return break_insn;
}

int main (void){
 test (my_test);
 return 0;
}



-- 
System  on Chip Design  Lab.
Dept. of Computer Science and Information Engineering,
National Chung Cheng University
E-mail : s88.tw@acm.org

Re: gdb breakpoint on x86

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb breakpoint on x86

[s88]

On 10/16/06, Daniel Jacobowitz <drow@false.org> 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

Re: gdb breakpoint on x86

[Frederic RISS]

On Mon, 2006-10-16 at 09:15 +0800, s88 wrote:
> > > 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!!

On Linux, GDB uses the ptrace(2) API to get access to another process'
address space. This API allows a debugger process to modify the memory
of another (debuggee) process. 

Looking at your segmentation fault issue, it's not a breakpoint issue,
it's a simple C issue AFAICT. You do:
  int *len=0;
  b = (my_byte *)i386_breakpoint_from_pc ((CORE_ADDR *)(t), len);

and in i386_breakpoint_from_pc:
  *len = sizeof (break_insn);

which is *0 = sizeof (break_insn);

That's also a memory protection error, but not due to editing executable
memory pages, it's simply a NULL pointer dereference.

Fred.

Re: gdb breakpoint on x86

[Jean-Marc Saffroy]

On Mon, 16 Oct 2006, s88 wrote:

> 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!!

Use mprotect to change your own mappings:

         char *p = target;

         p -= (unsigned long)p % PAGE_SIZE;
         if(mprotect(p, PAGE_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC)) {
                 perror("mprotect");
                 exit(1);
         }


> 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?

This size is architecture-specific, people use gdb on other CPU 
architectures as well. Look at i386_breakpoint_from_pc or 
ia64_breakpoint_from_pc for wildly different sizes (1 byte vs. 8 bytes).


-- 
saffroy@gmail.com