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

[Wolfgang Denk <wd@denx.de>]

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.