From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14809 invoked by alias); 2 Aug 2010 12:54:05 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 14796 invoked by uid 22791); 2 Aug 2010 12:54:04 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Mon, 02 Aug 2010 12:54: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: <20100802125122.GA2267@redhat.com> References: <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> <20100730144124.GA10396@redhat.com> <20100730152025.GA22951@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100730152025.GA22951@host1.dyn.jankratochvil.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00075.txt.bz2 On 07/30, Jan Kratochvil wrote: > > On Fri, 30 Jul 2010 16:41:24 +0200, Oleg Nesterov wrote: > > 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 ? > > So far I just assumed kernel-space ugdb is the plan. As I wrote before I do > not know gdbserver too much. I am not sure, but I do not really know. Jan, all, let me explain again what I think. Yes, as I said I personally do not believe in in-kernel gdbstub too much. If nothing else, I bet it will be never merged upstream. Unless at least this code will also have the more "traditional" user-space API which is immediately clear to the reviewers on lkml. And how we can implement, say, vRun in kernel? I am not saying this is technically impossible, but this against the common sense, imho. Or remote debugging via tcp. We need the user-space helper anyway. Again, of course it is technically possible to create the socket and the kernel thread which serves the requests, but I don't think we should do this. Or two modes, all-stop and non-stop. Imho, the kernel shouldn't even know about this. Or register renumbering. However. I have also said that my opinion doesn't matter. And I meant this! I do not understand the user-space needs, I do not understand the problems from the gdb's pov. So, we can put this code in kernel later, in the same module or another one if this is really needed. At least the prototyping is much easier in user-space. And I hope very much this helps to separate the utrace problems and the protocol problems. I may be wrong, but the most complex "conceptual" part is the thread management. I mean the very basic things: attach, detach, exit, clone. But, from the remore protocol pov these things do not exist, gdbserver hides this details. This is good for gdb, but complicates the testing and surely this is not enough in general. Just think about /bin/strace. Or. Currently I am not sure gdbstub does exactly same as the real gdbserver when the main thread exits. But I do not care at all, it would be trivial to change this user-level code if needed without changing the implementation details in kernel. > Catching up with systemtap's 200x higher software-watchpoint performance over > current (local) gdb (described in "[debug-list] Utrace Discussion Notes" off > this list) could be easier with in-kernel gdb I thought. Perhaps, I can't comment because I do not understand the problem space. Oleg.