From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23028 invoked by alias); 30 Jul 2010 13:00:32 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 23016 invoked by uid 22791); 30 Jul 2010 13:00:31 -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 13:00:00 -0000 From: Oleg Nesterov To: "Frank Ch. Eigler" Cc: Roland McGrath , utrace-devel@redhat.com, archer@sourceware.org Subject: Re: gdbstub initial code, another approach Message-ID: <20100730125755.GA6438@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00064.txt.bz2 On 07/29, Frank Ch. Eigler wrote: > > Oleg Nesterov writes: > > > [...] > > - ugdb.c > > > > The kernel module which implements the basic > > user-space API on top of utrace. Of course, > > this API should be discussed. > > - gdbstub > > > > The simple user-space gdbserver written in > > perl which works with ugdb API. > > [...] > > To the extent that the problems with an in-kernel gdbstub are > weaknesses in the protocol - or gdb's implementation thereof - how > would this split improve that situation? I have the strong desire to ask you by turn why do you think that in-kernel gdbstub can help in any way ;) Yes, I never liked the idea of in-kernel gdbstub. Apart from too-highlevel and vague it is also a bit limited. And some things, say, register renumbering, doesn't belong to kernel. Or vRun. Many other things. The only advantage is that we already have the great tool which works with this protocol - gdb. Ok, it is easy to criticize, and my opinion doesn't really matter. We can put it in kernel later, when we have something more than just the proof of concept. But I do not see how in-kernel gdbstub can help even to prototype things. In my opinion it only complicates this. If nothing else, it is not easy to test even the simple things. Just imagine the simple tests like ptrace-tests rewritten to work via remote protocol. IIUK, the main goal is prototype the new generic API, 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. It would be (I think) much easier to teach the real gdbserver and/or gdb to use this new API if we already had the userspace aplication which actually works using this API. OTOH, with this split we still have the same advantage: we can use gdb to prove that this code can do something useful. Oleg.