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

[Daniel Jacobowitz <drow at mvista dot com>]

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