This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: New "attach" and "rsh" features for GDB/gdbserver on PowerPC
- From: Wolfgang Denk <wd at denx dot de>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 04 Mar 2002 19:58:18 +0100
- Subject: Re: New "attach" and "rsh" features for GDB/gdbserver on PowerPC
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.