From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28980 invoked by alias); 3 Dec 2005 04:14:07 -0000 Received: (qmail 28973 invoked by uid 22791); 3 Dec 2005 04:14:06 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 03 Dec 2005 04:14:05 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EiOmg-0006GG-TE; Fri, 02 Dec 2005 23:14:03 -0500 Date: Sat, 03 Dec 2005 04:14:00 -0000 From: Daniel Jacobowitz To: Russell Shaw Cc: gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface Message-ID: <20051203041402.GA24030@nevyn.them.org> Mail-Followup-To: Russell Shaw , gdb@sourceware.org References: <200512022241.jB2Mf3Fk024314@elgar.sibelius.xs4all.nl> <8f2776cb0512021507m52b9d491gd4ddc0ceaab594ba@mail.gmail.com> <20051202233207.GA19812@nevyn.them.org> <8f2776cb0512021657i3f780f77sb1294b51753ffaaa@mail.gmail.com> <20051203023154.GA22527@nevyn.them.org> <439105DF.5040708@netspace.net.au> <20051203024500.GA22826@nevyn.them.org> <43910D47.2070300@netspace.net.au> <20051203033336.GA23537@nevyn.them.org> <43911985.9050901@netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43911985.9050901@netspace.net.au> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00024.txt.bz2 On Sat, Dec 03, 2005 at 03:05:25PM +1100, Russell Shaw wrote: > Well that's just too bad. It's the best way to go. Atleast i can support > my own private gdb and cut the cruft that's been holding it back for years. You can do that anyway. Maintain your own source tree based on a current release; it's not that hard, lots of people do this already. > The very concept of making a protocol conversion program act like an > end target is totally flawed. Obviously I disagree; I don't find any of the limitations you describe to be a serious problem in practice. And yes, we've written and used several of these shim layers here. > The second problem is that ICE hardware and other debuggers have > various specific commands such as for setting ICE hardware > parameters, selecting memory spaces, setting breakpoint paramteters, > and a ton of other stuff that a generic protocol has no hope of > addressing. Please see the "monitor" command, which lets you pass whatever you wish to the convertor. This and a couple of user-defined commands are most of what you need... > I found that by registering my own commands with add_com(), i can do > all kinds of excellent things such as spit out on the gdb output > window a tabulated list of the fuse settings in a microcontroller, or > display and set the current ICE hardware settings. ... and they can provide arbitrary output, also. If it's inadequate for what you want to do with it, please provide specific examples, and we can fix it. > With a defined interface for vendors to control specific debugger > hardware, gdb would get a lot more interest and move lightyears > ahead. All i've seen is stagnation ever since i've had an interest in > gdb 5 years ago. You might be surprised to know that there's a thriving market for this sort of conversion layer already, e.g. OCDRemote. As for the state of GDB, that's a separate thread, and making progress already. -- Daniel Jacobowitz CodeSourcery, LLC