From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12466 invoked by alias); 4 Mar 2002 18:58:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12270 invoked from network); 4 Mar 2002 18:58:40 -0000 Received: from unknown (HELO mailout05.sul.t-online.com) (194.25.134.82) by sources.redhat.com with SMTP; 4 Mar 2002 18:58:40 -0000 Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16hxfQ-0007ez-08; Mon, 04 Mar 2002 19:58:36 +0100 Received: from denx.de (320026445996-0001@[80.128.79.84]) by fmrl00.sul.t-online.com with esmtp id 16hxfL-1pQOkyC; Mon, 4 Mar 2002 19:58:31 +0100 Received: from denx.denx.de (denx.denx.de [10.0.0.2]) by denx.de (Postfix) with ESMTP id 8403636976; Mon, 4 Mar 2002 20:06:13 +0100 (MET) Received: by denx.denx.de (Postfix, from userid 15) id 42616109E9; Mon, 4 Mar 2002 19:58:23 +0100 (MET) Received: from denx.denx.de (localhost [127.0.0.1]) by denx.denx.de (Postfix) with ESMTP id 3CB90109E8; Mon, 4 Mar 2002 19:58:23 +0100 (MET) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: New "attach" and "rsh" features for GDB/gdbserver on PowerPC From: Wolfgang Denk X-Mailer: exmh version 2.2 Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Mon, 04 Mar 2002 12:01:55 EST." <20020304120155.A20045@nevyn.them.org> Date: Mon, 04 Mar 2002 10:58:00 -0000 Message-Id: <20020304185823.42616109E9@denx.denx.de> X-Sender: 320026445996-0001@t-dialin.net X-SW-Source: 2002-03/txt/msg00035.txt.bz2 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.