This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

New "attach" and "rsh" features for GDB/gdbserver on PowerPC


Hello,

please find attached a patch to gdb-5.1 that  adds  support  for  the
"attach"  command  and  a new "remote shell" command to GDB/gdbserver
for PowerPC systems.

ChangeLog entry:

---------------------------------------------------------------------

2002-03-04  Wolfgang Denk  <wd@denx.de>

        * add support for "attach" command and new "rshell" (remote
        shell) command to GDB/gdbserver for PowerPC systems.

        * make gdbserver "resident" if started without process
        argument (i. e. when started a server it does not terminate
        when a debugged process terminates)

---------------------------------------------------------------------

Description:

Many  embedded  systems  use  gdbserver  for  application  debugging.
However  the  current  implementation  (on PowerPC) requires that the
processes to be debugged are started under control of gdbserver.  But
often  you  want to debug (examine) some process on the target system
that is already running. This is supported by the new support for the
"attach" command.

This allows to have always one instance of gdbserver running  on  the
target  as  a general purpose debug server that can be used to attach
to any of the running application processes. In  this  "server  mode"
(when  no  command  to  debug is given on the gdbserver command line)
gdbserver will not terminate when the debugged  process  exits,  thus
making sure you can continue to use the debug server.

The "rshell" (remote shell) extension allows to use GDB/gdbserver  to
run arbitrary commands on the target system. The main intention is to
be  able  to find out the PIDs of the processes you want to attach to
by running a "ps" command without need for additional services on the
target.

A typical debugging session would thus look like this:


On the target:

	...
	# gdbserver :12345 &
	Ready to attach to a process
	# ./testcode ...
	...


On the host:

	$ powerpc-linux-gdb testcode
	...
	(gdb) target remote 192.168.3.17:12345
	Remote debugging using 192.168.3.17:12345
	(gdb) rsh ps ax
	  PID TTY      STAT   TIME COMMAND
	    1 ?        S      0:01 init
	    2 ?        SW     0:00 [keventd]
	    3 ?        SW     0:00 [kswapd]
	    4 ?        SW     0:00 [kreclaimd]
	    5 ?        SW     0:00 [bdflush]
	    6 ?        SW     0:00 [kupdated]
	    7 ?        SW     0:00 [mtdblockd]
	    8 ?        SW     0:00 [rpciod]
	   51 ?        S      0:00 /sbin/portmap
	   79 ?        S      0:00 /sbin/syslogd
	   81 ?        S      0:00 /sbin/klogd
	   86 ?        S      0:00 /usr/sbin/inetd
	   87 ttyS0    S      0:00 -bash
	   96 ttyS0    S      0:00 /tmp/gdbserver :12345
	   97 ttyS0    S      0:00 ./testcode ...
	   98 ttyS0    R      0:00 ps ax
	(gdb) attach 97
	Attaching to remote program `/home/wd/testcode' (process 97)...
	0x0ff631a4 in ?? ()
	(gdb) b 9
	Breakpoint 1 at 0x10000580: file testcode.c, line 9.
	(gdb) c
	Continuing.
	...


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek

Attachment: gdb-5.1.1.patch.gz
Description: gdb-5.1.1.patch.gz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]