placing a breakpoint at a physical address on x86 with gdb

placing a breakpoint at a physical address on x86 with gdb

[Mathieu Lacage]

hi,

I would like to place a breakpoint at a physical address only within a
single process: the idea is that I would like to be able to place a
single breakpoint to catch every call to a given function which could be
mapped at different virtual addresses within a single process.

As far as I can tell, x86 debug registers are of no help since they are
specified to interpret the breakpoint address before any virtual to
physical address translation happens. So, I would need to place multiple
local breakpoints, one for each address at which my function is mapped. 

Another way would be to map my function multiple times in memory but
manage to mark each mapping to shared the same underlying physical
memory and then insert an int3 breakpoint in the underlying physical
memory. However, I do not see any way to do this with the existing mmap
syscall: its MAP_PRIVATE flag will make each mapping independent of the
others (which is not what I want) while its MAP_SHARED will potentially
modify the underlying file when I insert the int3.

Yet another alternative would be to create a shared memory segment with
shm_open, copy the code of my function in there, create multiple memory
mappings with mmap (MAP_SHARED) on that shared memory segment and insert
an int3 in the shared memory segment whenever needed.

Is there anyone who could think of other, simpler, alternatives ?

Mathieu
-- 

Re: placing a breakpoint at a physical address on x86 with gdb

[Mathieu Lacage]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Fri, 2007-01-12 at 12:41 +0100, Mathieu Lacage wrote:

> Yet another alternative would be to create a shared memory segment with
> shm_open, copy the code of my function in there, create multiple memory
> mappings with mmap (MAP_SHARED) on that shared memory segment and insert
> an int3 in the shared memory segment whenever needed.

and the attached test code demonstrates this.

Mathieu
-- 

[-- Attachment #2: test-mmap.c --]
[-- Type: text/x-csrc, Size: 2046 bytes --]

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <assert.h>
#include <errno.h>
#include <string.h>


#define BUFFER_SIZE (1024)

int main (int argc, char *argv[])
{
  int file_fd, shm_fd;
  struct stat stat_buffer;
  char buffer[BUFFER_SIZE];
  int retval;
  off_t left;
  file_fd = open ("./test-mmap.c", O_RDONLY);
  retval = fstat(file_fd, &stat_buffer);
  assert (retval != -1);
  shm_fd = shm_open ("my-test", O_RDWR | O_CREAT, S_IRWXU);
  assert (shm_fd != -1);
  retval = ftruncate (shm_fd, stat_buffer.st_size);
  assert (retval != -1);
  left = stat_buffer.st_size;
  while (left > 0) {
    off_t to_read;
    ssize_t actually_read;
    ssize_t actually_written;
    if (left > BUFFER_SIZE) {
      to_read = BUFFER_SIZE;
    } else {
      to_read = left;
    }
    actually_read = read (file_fd, buffer, to_read);
    assert (actually_read != -1);
    actually_written = write (shm_fd, buffer, actually_read);
    assert (actually_written == actually_read);
    left -= actually_read;
  }
  close (file_fd);

  printf ("done copying file to shared memory\n");

  // Here, we have a shared memory segment which contains the content of our file.

  {
    void *map_one;
    void *map_two;
    char *one;
    char *two;
    map_one = mmap (0, stat_buffer.st_size, PROT_READ | PROT_EXEC | PROT_WRITE, MAP_SHARED, shm_fd, 0);
    assert (map_one != MAP_FAILED);
    map_two = mmap (0, stat_buffer.st_size, PROT_READ | PROT_EXEC | PROT_WRITE, MAP_SHARED, shm_fd, 0);
    assert (map_two != MAP_FAILED);

    one = map_one;
    two = map_two;
    printf ("one=%c\n", one[10]);
    printf ("two=%c\n", two[10]);    
    one[10] = 'Y';
    msync (map_one, stat_buffer.st_size, MS_SYNC);
    printf ("one=%c\n", one[10]);
    printf ("two=%c\n", two[10]);    


    retval = munmap (map_one, stat_buffer.st_size);
    assert (retval != -1);
    retval = munmap (map_two, stat_buffer.st_size);
    assert (retval != -1);
  }


  return 0;
}

help string for "break" command

[Mathieu Lacage]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

hi,

Am I right in assuming that the gdb command "break" places exclusively
so-called software-breakpoints while the command "hbreak" places a
hardware-breakpoint (I am not sure I have figured out the details of the
logic in gdb/breakpoint.c) ? 

If so, maybe the gdb help should be updated to reflect this difference
more prominently: the current help string for "break" do not specify
clearly that it is a software-breakpoint. The attached patch changes the
relevant string.

regards,
Mathieu
-- 

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 455 bytes --]

--- breakpoint.old	2007-01-12 14:38:50.000000000 +0100
+++ breakpoint.c	2007-01-12 14:39:32.000000000 +0100
@@ -7928,7 +7928,7 @@
 See also the \"delete\" command which clears breakpoints by number."));
 
   c = add_com ("break", class_breakpoint, break_command, _("\
-Set breakpoint at specified line or function.\n"
+Set software breakpoint at specified line or function.\n"
 BREAK_ARGS_HELP ("break")));
   set_cmd_completer (c, location_completer);
 

Re: help string for "break" command

[Daniel Jacobowitz]

On Fri, Jan 12, 2007 at 02:45:16PM +0100, Mathieu Lacage wrote:
> Am I right in assuming that the gdb command "break" places exclusively
> so-called software-breakpoints while the command "hbreak" places a
> hardware-breakpoint (I am not sure I have figured out the details of the
> logic in gdb/breakpoint.c) ? 

Not 100%.  CVS versions of GDB will use hardware breakpoints
automatically if you try to set them in truly read-only memory.

-- 
Daniel Jacobowitz
CodeSourcery

Re: help string for "break" command

[Mathieu Lacage]

On Fri, 2007-01-12 at 08:49 -0500, Daniel Jacobowitz wrote:
> On Fri, Jan 12, 2007 at 02:45:16PM +0100, Mathieu Lacage wrote:
> > Am I right in assuming that the gdb command "break" places exclusively
> > so-called software-breakpoints while the command "hbreak" places a
> > hardware-breakpoint (I am not sure I have figured out the details of the
> > logic in gdb/breakpoint.c) ? 
> 
> Not 100%.  CVS versions of GDB will use hardware breakpoints
> automatically if you try to set them in truly read-only memory.

I see the following comment in the CVS version:
          /* If the explicitly specified breakpoint type
             is not hardware breakpoint, check the memory map to see
             if the breakpoint address is in read only memory or not.
             Two important cases are:
             - location type is not hardware breakpoint, memory
             is readonly.  We change the type of the location to
             hardware breakpoint.
             - location type is hardware breakpoint, memory is read-write.
             This means we've previously made the location hardware one, but
             then the memory map changed, so we undo.

             When breakpoints are removed, remove_breakpoints will
             use location types we've just set here, the only possible
             problem is that memory map has changed during running program,
             but it's not going to work anyway with current gdb.  */

and it seems to match the decision logic I see below.

Would there be opposition to an 'sbreak' command which would ensure that
a software breakpoint is used _all the time_ ? 

Mathieu
-- 

Re: help string for "break" command

[Daniel Jacobowitz]

On Fri, Jan 12, 2007 at 03:19:31PM +0100, Mathieu Lacage wrote:
> Would there be opposition to an 'sbreak' command which would ensure that
> a software breakpoint is used _all the time_ ? 

I would certainly object unless you could give a good reason why
there should be one.  We have too many marginal commands already.
Note, "read only" in a Unix VM sense does not have anything to do
with this decision; ptrace overrides that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: help string for "break" command

[Bob Rossi]

On Fri, Jan 12, 2007 at 03:19:31PM +0100, Mathieu Lacage wrote:
> On Fri, 2007-01-12 at 08:49 -0500, Daniel Jacobowitz wrote:
> > On Fri, Jan 12, 2007 at 02:45:16PM +0100, Mathieu Lacage wrote:
> > > Am I right in assuming that the gdb command "break" places exclusively
> > > so-called software-breakpoints while the command "hbreak" places a
> > > hardware-breakpoint (I am not sure I have figured out the details of the
> > > logic in gdb/breakpoint.c) ? 
> > 
> > Not 100%.  CVS versions of GDB will use hardware breakpoints
> > automatically if you try to set them in truly read-only memory.
> 
> I see the following comment in the CVS version:
>           /* If the explicitly specified breakpoint type
>              is not hardware breakpoint, check the memory map to see
>              if the breakpoint address is in read only memory or not.
>              Two important cases are:
>              - location type is not hardware breakpoint, memory
>              is readonly.  We change the type of the location to
>              hardware breakpoint.
>              - location type is hardware breakpoint, memory is read-write.
>              This means we've previously made the location hardware one, but
>              then the memory map changed, so we undo.
> 
>              When breakpoints are removed, remove_breakpoints will
>              use location types we've just set here, the only possible
>              problem is that memory map has changed during running program,
>              but it's not going to work anyway with current gdb.  */
> 
> and it seems to match the decision logic I see below.
> 
> Would there be opposition to an 'sbreak' command which would ensure that
> a software breakpoint is used _all the time_ ? 

Is the 'set breakpoint auto-hw off' helpful here?

http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC32

Bob Rossi

Re: help string for "break" command

[Mathieu Lacage]

On Fri, 2007-01-12 at 09:26 -0500, Bob Rossi wrote:

[snip]

> > Would there be opposition to an 'sbreak' command which would ensure that
> > a software breakpoint is used _all the time_ ? 
> 
> Is the 'set breakpoint auto-hw off' helpful here?
> 
> http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC32

This looks like what I was after.

thanks,
Mathieu
-- 

Re: help string for "break" command

[mathieu lacage]

On Fri, 2007-01-12 at 08:49 -0500, Daniel Jacobowitz wrote:
> On Fri, Jan 12, 2007 at 02:45:16PM +0100, Mathieu Lacage wrote:
> > Am I right in assuming that the gdb command "break" places exclusively
> > so-called software-breakpoints while the command "hbreak" places a
> > hardware-breakpoint (I am not sure I have figured out the details of the
> > logic in gdb/breakpoint.c) ? 
> 
> Not 100%.  CVS versions of GDB will use hardware breakpoints
> automatically if you try to set them in truly read-only memory.

hrm, I have actually tried to get the cvs version of gdb to use hw
breakpoints using this 'automatic' conversion but failed to ever get it
to trigger. Is there a way to make gdb print the target memory map it
uses to make this decision ? I tried the following:
(gdb) info mem
Using memory regions provided by the target.
There are no memory regions defined.
(gdb) 

Which leads me to suspect that my current target (x86 linux FC6) does
not implement this so, the memory region lookup code returns the default
region all the time which contains an RW attr. Is this expected ? Did I
somehow screw up the configuration stage ?

regards,
Mathieu

Re: help string for "break" command

[Daniel Jacobowitz]

On Fri, Jan 12, 2007 at 07:11:14PM +0100, mathieu lacage wrote:
> Which leads me to suspect that my current target (x86 linux FC6) does
> not implement this so, the memory region lookup code returns the default
> region all the time which contains an RW attr. Is this expected ?

That is correct.  As I wrote in a reply earlier, this does not apply
to the notion of "read-only" used by Unix VM systems, where the OS
can create a COW copy for us to use.  It's for debugging ROM images.

-- 
Daniel Jacobowitz
CodeSourcery