Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Using Captured Storage for Accessing Debug Break Points and Storage

IP.com Disclosure Number: IPCOM000118360D
Original Publication Date: 1996-Dec-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 3 page(s) / 134K

Publishing Venue

IBM

Related People

Ault, DF: AUTHOR [+3]

Abstract

Disclosed is a method allowing a debugger process to access the storage of the application process being debugged, without resorting to cross memory mechanisms. The method uses a variation of shared memory to allow the debugger immediate access to the application program and dynamid storage.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

Using Captured Storage for Accessing Debug Break Points and Storage

      Disclosed is a method allowing a debugger process to access the
storage of the application process being debugged, without resorting
to cross memory mechanisms.  The method uses a variation of shared
memory to allow the debugger immediate access to the application
program and dynamid storage.

      In operating systems that use fork to create work, debuggers
have evolved that use a function called PTRACE to access storage in
the process being debugged.  Each time the debugger code wants to set
a breakpoint or interrogate storage in the process being debugged, it
is necessary to perform authorized system functions to gain access to
the storage and to return that information to the debugger.

      Since debuggers make frequent accesses to the storage of the
process being debugged, it is desirable for these accesses to be
processed quickly.  Unfortunately, the overhead of crossing a process
boundary tends to be a costly operation on most operating systems.

      The solution to this problem is to provide a mechanism which
can be called by the debugger to map storage from the debugged
process to storage that resides in the debugger address space.  With
local access to the storage, the debugger can access and modify the
local copy of the storage and have the change appear in the debugged
processes storage.

A little background on this is now appropriate:
  o  Common Storage
       Some operating systems support a concept of common
      storage.  Common storage is virtual storage that has
      the same virtual address in all processes.  This
      storage has a single virtual address and a single
      real page that backs the virtual page.
  o  Shared Memory
       Some operating systems support a function called shared
      memory.  Shared memory provides the ability of multiple
      processes to define an area of storage which can be
      accessed by all of the processes.  Each process has this
      shared memory mapped to a virtual address within their
      process.  The virtual address within each of the processes
      may be different, but the real pages that back the shared
      memory is the same for all the sharing processes.
  o  Captured Storage
       Another concept that exists on systems which support fork
      is the notion of captured storage.  In this scenario, the
      operating system uses system services to capture the storage
      of the parent in the child process.  This allows both the
      parent and child to share the same real pages until either
      the parent or child no longer needs it.  This is just
      another case of having a process with its own virtual
      addresses which share real pages with another process.
  o  Capture Storage
       This invention makes the assumption t...