FW: The question about the relation between gdb and the programme debugged

FW: The question about the relation between gdb and the programme debugged

[Lawrence Lee (Shanghai)]

-----Original Message-----
From: Lawrence Lee (Shanghai) 
Sent: Tuesday, June 11, 2002 9:31 AM
To: 'Kevin Buettner'
Cc: gdb
Subject: RE: The question about the relation between gdb and the
programme debugged


Thanks!
But how does the gdb process access the memory spaces in the program being
debugged?
If the object program uses ioperm and iopl to get the permission to
read(write) IO port, can the gdb access the IO port also?

Thanks.

-----Original Message-----
From: Kevin Buettner [mailto:kevinb@redhat.com]
Sent: Tuesday, June 11, 2002 5:50 AM
To: Lawrence Lee (Shanghai); 'gdb@sources.redhat.com'
Subject: Re: The question about the relation between gdb and the
programme deb ugged


On Jun 10, 10:11am, Lawrence Lee (Shanghai) wrote:

> I want to know the relation between the gdb and the object programme being
> debugged. Does the gdb load the object programme into  gdb's memory spaces
> so that gdb can access the varible of the programme? Or the gdb and the
> object programme are different processes which have different memory
> spaces?

The latter; gdb and the program being debugged are separate processes.

Kevin

Re: The question about the relation between gdb and the programme debugged

[Kevin Buettner]

On Jun 11,  9:33am, Lawrence Lee (Shanghai) wrote:

> But how does the gdb process access the memory spaces in the program being
> debugged?

It depends.  For a "native" debugger, the operating system's kernel
provides an interface by which the debugger can read/write the memory
of the process being debugged.  On GNU/Linux (and many other unices),
ptrace() is the interface by which the debugger accesses and controls
memory, registers, and other aspects of the inferior program.  "Pure"
SVR4 systems use the use the /proc filesystem for this interface.

For a remote debugger, the target machine has a debugging "stub"
running on it which provides access to memory, registers, etc.  (GDB
communicates with the stub via a serial port, ethernet, usb, etc.) The
stub may use the same type of interface as described above for a
native debugger to access memory, registers, etc.  Or, if the OS on
the target in question is not very sophisticated, it may simply access
memory directly.

> If the object program uses ioperm and iopl to get the permission to
> read(write) IO port, can the gdb access the IO port also?

Again, it depends.  On most unix systems, this sort of thing is
a security hole and is usually disallowed.  But when using a "cross"
debugger with a remote board, it may be that the OS of the board will
allow access it IO ports.

Kevin