From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16412 invoked by alias); 30 Jul 2010 14:44:00 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 16396 invoked by uid 22791); 30 Jul 2010 14:43:57 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Fri, 30 Jul 2010 14:44:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: "Frank Ch. Eigler" , Roland McGrath , utrace-devel@redhat.com, archer@sourceware.org Subject: Re: gdbstub initial code, another approach Message-ID: <20100730144124.GA10396@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> <20100721204203.D040C400B6@magilla.sf.frob.com> <20100723173134.GA29717@redhat.com> <20100726142759.GA17171@redhat.com> <20100728181702.GA26678@redhat.com> <20100730125755.GA6438@redhat.com> <20100730132537.GA15448@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100730132537.GA15448@host1.dyn.jankratochvil.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00067.txt.bz2 On 07/30, Jan Kratochvil wrote: > > On Fri, 30 Jul 2010 14:57:55 +0200, Oleg Nesterov wrote: > > IIUK, the main goal is prototype the new generic API, > > As I thought there is an agreement the ptrace API has to stay. Of course, ptrace can't go away. > We definitely need some serialized protocol as we need remote debugging with > multiple inferiors for cloud. Nobody argues. > I do not see why to create a new layer (your `new generic API') between kernel > and gdbserver-in-userland. Because gdb is not alone? I agree, it is probably most important. > > while the remote protocol (in my opinion) is obviously can't be considered > > as such. With this split it is possible to try to add some API and test it > > with or without gdb. Also, it is much more easy to play with the the > > protocol extensions (which I believe it needs) this way. > > If it is only a development tool for the in-kernel server then OK. Right now I do not know. > > It would be (I think) much easier to teach the real > > gdbserver and/or gdb to use this new API > > gdb linux-nat.c (=local gdb) should be deprecated. There is definitely a need > for remote target and actively maintaining two modes is not effective, we can > run gdbserver even during single-host debugging. OK, > We can port gdbserver to anything but I do not see the point. We should > probably move the threading support from gdbserver to gdb but there isn't much > left to do in userland gdbserver with properly designed kernel API. IOW, you think that it is better to shift gdbserver into kernel-space than port the existing one to the new API or write the new one in user space ? Oleg.