From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23260 invoked by alias); 30 Jul 2010 13:25:55 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 23242 invoked by uid 22791); 30 Jul 2010 13:25:54 -0000 X-SWARE-Spam-Status: No, hits=-6.0 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 13:25:00 -0000 From: Jan Kratochvil To: Oleg Nesterov Cc: "Frank Ch. Eigler" , Roland McGrath , utrace-devel@redhat.com, archer@sourceware.org Subject: Re: gdbstub initial code, another approach Message-ID: <20100730132537.GA15448@host1.dyn.jankratochvil.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100730125755.GA6438@redhat.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-SW-Source: 2010-q3/txt/msg00066.txt.bz2 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. ptrace as an API is really ugly but it works. GDB internally already has an abstraction on top of it (linux-nat.c as a target). We definitely need some serialized protocol as we need remote debugging with multiple inferiors for cloud. The gdb remote protocol is already very thin to just provide some "ptrace-like" functionality serialized over the wire. I already tried (test only, not indended for a production) once to "replace ptrace" with disagreement on the design: Re: Proof-of-concept on fd-connected linux-nat.c server http://sourceware.org/ml/archer/2009-q2/msg00082.html I do not see why to create a new layer (your `new generic API') between kernel and gdbserver-in-userland. > 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. > 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. 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. Thanks, Jan