From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16995 invoked by alias); 16 Nov 2010 20:02:41 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 16984 invoked by uid 22791); 16 Nov 2010 20:02:40 -0000 X-SWARE-Spam-Status: No, hits=-4.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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov X-Fcc: ~/Mail/utrace Cc: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: gdbstub initial code, v16 In-Reply-To: Oleg Nesterov's message of Monday, 15 November 2010 20:05:37 +0100 <20101115190537.GA15725@redhat.com> References: <20101115190537.GA15725@redhat.com> Message-Id: <20101116200226.BDD7B40147@magilla.sf.frob.com> Date: Tue, 16 Nov 2010 20:02:00 -0000 X-SW-Source: 2010-q4/txt/msg00029.txt.bz2 > Well. I can't say this change is good. Because ugdb uses (unexported) > arch_ptrace() to set debugregs in a very much x86-specific way. However, > I do not see what else can I do. That kludge is unworkable in several ways. It is just not worth pursuing. Just use hw_breakpoint on kernels that have it, and don't try to support the feature on kernels that don't. > Say, should I implement vRun? From the very beginnig, I hate the idea > to exec the target from kernel space, but otoh I'm afraid this is > important for gdb users. We've also vaguely discussed doing some hybrid solution where gdb does something different for "run". If you can do a kludge to implement vRun fairly quickly and it works OK--including that it remains possible for ugdb to be a module--then go ahead. If that is too ungainly, or is just plain infeasible (which I think it might be), then don't bend over backwards for it. We may have reached the end of what it's possible to get done at all sensibly without more active involvement from the GDB team. Thanks, Roland