From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18300 invoked by alias); 25 Jul 2012 14:16:36 -0000 Received: (qmail 18275 invoked by uid 22791); 25 Jul 2012 14:16:33 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 14:16:19 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Su2Nu-0004K3-6h from Hafiz_Abid@mentor.com ; Wed, 25 Jul 2012 07:16:18 -0700 Received: from SVR-IES-FEM-04.mgc.mentorg.com ([137.202.0.110]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jul 2012 07:16:17 -0700 Received: from EU-MBX-03.mgc.mentorg.com ([169.254.2.57]) by SVR-IES-FEM-04.mgc.mentorg.com ([137.202.0.110]) with mapi id 14.01.0289.001; Wed, 25 Jul 2012 15:16:16 +0100 From: "Abid, Hafiz" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: RE: [patch] MI telnet service Date: Wed, 25 Jul 2012 14:16:00 -0000 Message-ID: References: <20120725130222.GA4538@host2.jankratochvil.net> In-Reply-To: <20120725130222.GA4538@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00526.txt.bz2 Hi Jan, Thanks for the review. Some comments inline. > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Wednesday, July 25, 2012 2:02 PM > To: Abid, Hafiz > Cc: gdb-patches@sourceware.org > Subject: Re: [patch] MI telnet service >=20 > Hi Abid, >=20 > the testcase is mixing host vs. target execution. You connect to the > port > from the .c program but that can run on a different machine than the > .exp > program is running. It would be better to connect to the port from the > .exp > file, in fact you do not need any .c program there at all. Or if the > test > would be done from .c file then you need to skip the test if [is_remote > target]. I agree that it is better to just test the port from exp file and drop the = c file.=20 > (It could run if the target is remote but still "localhost" or "stdio" > but > that is currently not supported in the GDB testsuite.) >=20 > "gdbmitel" is too cryptic, the option can be very long, with words > separated > by dashes. Ok. >=20 > Have you talked to Eclipse maintainers why they do not provide separate > console? In fact they do, I find it more fits there. If communication > with > Eclipse developers has failed GDB can implement it, but I find it more > as > Eclipse workaround. >=20 > It does not support IPv6. GDB currently also does not (for connections > to > gdbserver) but that is a bug, I tried to fix it, I hope to resurrect > the patch > sometimes again: > [patch] IPv6 support for gdbserver > http://sourceware.org/ml/gdb-patches/2006-09/msg00192.html > http://sourceware.org/ml/gdb-patches/2006-10/msg00073.html >=20 > Opening the port INADDR_ANY should be possible but only with some > additional > -start-telnet-service option, services usually open only with > INADDR_LOOPBACK > by default. Still there is missing security on multi-user systems, this > is one > of the reasons an interface through Eclipse would be more logical to > me. >=20 > You do not print any errors, such as in: > +/* This is wrapper over recv. If recv returns some error then it > closes > + the socket. */ > +static int > +receive (int *fd, void *buf, size_t n, int flags) > I believe it could be output as: > Node: GDB/MI Stream Records > `"&" STRING-OUTPUT' > The log stream contains debugging messages being produced by GDB's > internals. I will fix it. >=20 > I find it only as a last resort possibility now without readline > support. > Could it support $TERM negotiation like telnetd supports and attach > readline > to it? Actually I have worked on negotiating the mode with telnet and then connect= ing the incoming data to readline. But all this was making the patch quite = complicated. So I thought to go with a simple patch first and then add the = readline letter.=20 There has been some suggestions about making it a CLI command. But in that = case, we will not be able to attach readline to the socket input as readlin= e is already connected with CLI. I think readline cannot handle 2 parallel = streams. >=20 >=20 > Thanks, > Jan