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

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

[Wolfgang Denk]

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

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 #2: gdb-5.1.1.patch.gz --]
[-- Type: application/x-gzip , Size: 21916 bytes --]

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

[Daniel Jacobowitz]

Lots of comments follow.  Some of this patch is quite interesting - I
like the idea of a resident daemon mode.  But you have a few problems
that will need to be fixed first.

On Mon, Mar 04, 2002 at 10:13:57AM +0100, Wolfgang Denk wrote:
> 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.

GDBserver has been almost entirely rewritten since 5.1 was released. 
I'd appreciate it if you could try to merge this to current CVS.  That
should let it go into 5.3 (5.2 is scheduled for release in about a
month and has already branched).

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

The (i.e. ) bit can already be accomplished using target
extended-remote instead of target remote.  This still has some
interesting applications though.

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

I added --attach to gdbserver on Jan. 17th.

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

This needs to be enabled by an explicit command line option to
gdbserver, and well documented.  Bear in mind that the remote protocol
has -NO- authentication, even IP based.  This makes it much too trivial
to gain access to the target system by intercepting a debug session. 
It was already possible, but at least it took a little thought...


[Non-MIME patches are prefered on this list.]

> --- gdb-5.1.1/gdb/configure.ORIG	Thu Aug  2 23:30:20 2001
> +++ gdb-5.1.1/gdb/configure	Sun Feb 24 23:14:45 2002

Also, please don't include patches to generated files.  And do include
ChangeLog entries.  Standard GNU policy...

> + diff -Nrup gdb-5.1.1/gdb/acconfig.h.ORIG gdb-5.1.1/gdb/acconfig.h
> --- gdb-5.1.1/gdb/acconfig.h.ORIG	Sat Mar 31 20:09:02 2001
> +++ gdb-5.1.1/gdb/acconfig.h	Sun Feb 24 23:14:45 2002
> @@ -170,3 +170,10 @@
>  
>  /* nativefile */
>  #undef GDB_NM_FILE
> +
> +/* define to have target attach feature */
> +#undef HAVE_TARGET_ATTACH
> +
> +/* define to have target remote shell feature */
> +#undef HAVE_TARGET_SHELL
> +

Why do you bother doing this...

> + diff -Nrup gdb-5.1.1/gdb/configure.in.ORIG gdb-5.1.1/gdb/configure.in
> --- gdb-5.1.1/gdb/configure.in.ORIG	Thu Aug  2 23:30:22 2001
> +++ gdb-5.1.1/gdb/configure.in	Sun Feb 24 23:14:45 2002
> @@ -50,6 +50,8 @@ CONFIG_ALL=
>  CONFIG_CLEAN=
>  CONFIG_INSTALL=
>  CONFIG_UNINSTALL=
> +AC_DEFINE(HAVE_TARGET_ATTACH)
> +AC_DEFINE(HAVE_TARGET_SHELL)
>  
>  configdirs="doc testsuite"
>  

If you are just going to do that?  I believe that by doing this you
also broke compilation of gdbserver for any target that didn't
implement process_attach.

> + static char *shells[] = {
> +	"/bin/sh", "/bin/bash", "/bin/tcsh",
> +	"/usr/bin/sh", "/usr/bin/bash", "/usr/bin/tsch", (char *)0};

Why not assume /bin/sh?  I've never seen a Linux system that would
successfully boot without it, and silently switching to tcsh can cause
nothing but confusion.

> +    default:	/* Parent - gdbserver */
> +      close(fd[1]);	/* To get EOF properly */
> +      enable_async_io();
> +      inferior_pid = pid;		/* fake process ID */
> +      while (1)
> +	{
> +          if ((len = read(fd[0], buf, sizeof buf)) > 0)
> +	    {
> +	      write(remote_desc, &len, 1);
> +	      write(remote_desc, buf, len);
> +	    }
> +	  else if (len != -1 || errno != EINTR)
> +	    break;
> +	}
> +      write(remote_desc, &len, 1);	/* end mark (0) */
> +      waitpid(pid, (void *)0, 0);
> +      inferior_pid = saved_pid;
> +      disable_async_io();
> +    }
> +}

This should support receiving a control-c from GDB and passing it on to
the target process (or perhaps SIGTERM/SIGKILL ing the target
process!).  Otherwise it's a real easy way to hang your resident
gdbserver.  I see some support for that; is it really enough?

Also, if the program receives a signal at an inopportune time you'll
not collect it properly.  Should that waitpid check WIFEXITED?

> @@ -2040,6 +2052,20 @@ remote_start_remote (PTR dummy)
>    get_offsets ();		/* Get text, data & bss offsets */
>  
>    putpkt ("?");			/* initiate a query from remote machine */
> +#ifdef HAVE_TARGET_ATTACH
> +  getpkt(buf, PBUFSIZ, 0);
> +  if (buf[0] == 'E')
> +    {
> +      error ("Remote failure reply: %s", buf);
> +    } else
> + if (buf[0] == 'I')
> +    {
> +      inferior_ptid = null_ptid;
> +      return 1;			/* Remote server is idle waiting for attach */
> +    }
> +  putpkt ("?");			/* wait_for_inferior() called in start_remote
> +				   expects "wait status" packet */
> +#endif
>    immediate_quit--;
>  
>    return remote_start_remote_dummy (dummy);

You've checked that this still works with an unmodified stub, right?

> @@ -2148,6 +2174,9 @@ serial device is attached to the remote 
>  
>    unpush_target (target);
>  
> +#ifdef HAVE_TARGET_ATTACH
> + reread_symbols();
> +#endif 
>    remote_desc = serial_open (name);
>    if (!remote_desc)
>      perror_with_name (name);

This is necessary even now, and should probably be submitted as a
separate patch.  If you detach and then re-attach and the
executable has changed, we should reread symbols.  Thanks.

> @@ -2245,6 +2278,9 @@ serial device is attached to the remote 
>  
>    unpush_target (target);
>  
> +#ifdef HAVE_TARGET_ATTACH
> + reread_symbols();
> +#endif 
>    remote_desc = serial_open (name);
>    if (!remote_desc)
>      perror_with_name (name);

Likewise, of course.


For the rest, you are extending the remote protocol; you can't do that
just by submitting the feature, it needs to be discussed first.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Wolfgang Denk]

Daniel,

thanks for your reply.

In message <20020304120155.A20045@nevyn.them.org> you wrote:
>
> Lots of comments follow.  Some of this patch is quite interesting - I
> like the idea of a resident daemon mode.  But you have a few problems
> that will need to be fixed first.

Actually _I_ don't have problems - it's working for me :-)

> GDBserver has been almost entirely rewritten since 5.1 was released. 
> I'd appreciate it if you could try to merge this to current CVS.  That
> should let it go into 5.3 (5.2 is scheduled for release in about a
> month and has already branched).

OK, I'll try to merge it.

> > 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.
> 
> This needs to be enabled by an explicit command line option to
> gdbserver, and well documented.  Bear in mind that the remote protocol
> has -NO- authentication, even IP based.  This makes it much too trivial
> to gain access to the target system by intercepting a debug session. 

Ummm... there is no security on a system where gdbserver is  running,
that  much  is  clear.  I  don't  see any significant changes in that
respect - I could manually start commands before.

> It was already possible, but at least it took a little thought...

Right; it was possible, just difficult to describe to  Johnny  Loser,
and not acceptable to a customer. That's why we added a simpler way.

> [Non-MIME patches are prefered on this list.]

I see.

> > + static char *shells[] = {
> > +	"/bin/sh", "/bin/bash", "/bin/tcsh",
> > +	"/usr/bin/sh", "/usr/bin/bash", "/usr/bin/tsch", (char *)0};
> 
> Why not assume /bin/sh?  I've never seen a Linux system that would
> successfully boot without it, and silently switching to tcsh can cause
> nothing but confusion.

Many of our systems don't have a shell at all...


> This should support receiving a control-c from GDB and passing it on to
> the target process (or perhaps SIGTERM/SIGKILL ing the target
> process!).  Otherwise it's a real easy way to hang your resident
> gdbserver.  I see some support for that; is it really enough?

It worked for the tests we did...

> Also, if the program receives a signal at an inopportune time you'll
> not collect it properly.  Should that waitpid check WIFEXITED?

Probably you are right.


> For the rest, you are extending the remote protocol; you can't do that
> just by submitting the feature, it needs to be discussed first.

Can we then consider this as the start of the discussion?

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.

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

[Michael Snyder]

Wolfgang Denk wrote:

> > For the rest, you are extending the remote protocol; you can't do that
> > just by submitting the feature, it needs to be discussed first.
> 
> Can we then consider this as the start of the discussion?

I would recommend splitting the submission into at least two 
orthogonal submissions.

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

[Daniel Jacobowitz]

On Mon, Mar 04, 2002 at 07:58:18PM +0100, Wolfgang Denk wrote:
> Daniel,
> 
> thanks for your reply.
> 
> In message <20020304120155.A20045@nevyn.them.org> you wrote:
> >
> > Lots of comments follow.  Some of this patch is quite interesting - I
> > like the idea of a resident daemon mode.  But you have a few problems
> > that will need to be fixed first.
> 
> Actually _I_ don't have problems - it's working for me :-)
> 
> > GDBserver has been almost entirely rewritten since 5.1 was released. 
> > I'd appreciate it if you could try to merge this to current CVS.  That
> > should let it go into 5.3 (5.2 is scheduled for release in about a
> > month and has already branched).
> 
> OK, I'll try to merge it.

Thanks greatly!

> > > 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.
> > 
> > This needs to be enabled by an explicit command line option to
> > gdbserver, and well documented.  Bear in mind that the remote protocol
> > has -NO- authentication, even IP based.  This makes it much too trivial
> > to gain access to the target system by intercepting a debug session. 
> 
> Ummm... there is no security on a system where gdbserver is  running,
> that  much  is  clear.  I  don't  see any significant changes in that
> respect - I could manually start commands before.

Then I'll withdraw this objection, and talk about how much more clearly
we need to document this fact.

Or just add some sort of trivial authentication, and leave me less
scared of what my users are up to!

> > > + static char *shells[] = {
> > > +	"/bin/sh", "/bin/bash", "/bin/tcsh",
> > > +	"/usr/bin/sh", "/usr/bin/bash", "/usr/bin/tsch", (char *)0};
> > 
> > Why not assume /bin/sh?  I've never seen a Linux system that would
> > successfully boot without it, and silently switching to tcsh can cause
> > nothing but confusion.
> 
> Many of our systems don't have a shell at all...

Sure.  I wasn't suggesting you remove that code for handling no shell. 
Just the code for finding a sh-alike to use.

> > This should support receiving a control-c from GDB and passing it on to
> > the target process (or perhaps SIGTERM/SIGKILL ing the target
> > process!).  Otherwise it's a real easy way to hang your resident
> > gdbserver.  I see some support for that; is it really enough?
> 
> It worked for the tests we did...
> 
> > Also, if the program receives a signal at an inopportune time you'll
> > not collect it properly.  Should that waitpid check WIFEXITED?
> 
> Probably you are right.
> 
> 
> > For the rest, you are extending the remote protocol; you can't do that
> > just by submitting the feature, it needs to be discussed first.
> 
> Can we then consider this as the start of the discussion?

Please bring this up separately on gdb@sources.redhat.com, where it
belongs.  We can't consider it as the start of the discussion, because
you haven't described what the extensions actually are.  Documentation
(or at least description) before code!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

Sigh, some paper work.

Wolfgang,
I don't see any copyright assignment for GDB changes with the FSF on 
file.  If you don't have an assignment then can you please let JimB 
(CC'd) know so that this can be sorted out.

Andrew

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

[Andrew Cagney]

Just FYI,
> 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.

I get the feeling that this change is pretty sigifnicant in terms of the 
protocol (new ``I'' response, new attach packet, ...?).  Could you 
please post something describing what you plan on changing.

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

BTW,  there is already the ``(gdb) monitor'' command and the 
corresponding ``qRcmd'' packet.

As a general rule, features are always present - using #ifdef 
HAVE_TARGET_ATTACH #ifdef FOO #else #endif is probably not a good idea.

enjoy,
Andrew