From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3836 invoked by alias); 3 Dec 2005 05:25:47 -0000 Received: (qmail 3829 invoked by uid 22791); 3 Dec 2005 05:25:46 -0000 X-Spam-Check-By: sourceware.org Received: from cumulus.netspace.net.au (HELO mail.netspace.net.au) (203.10.110.72) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 05:25:45 +0000 Received: from [192.168.0.10] (220-253-18-66.VIC.netspace.net.au [220.253.18.66]) by mail.netspace.net.au (Postfix) with ESMTP id 5E1447C6CD for ; Sat, 3 Dec 2005 16:25:40 +1100 (EST) Message-ID: <43912C55.7090708@netspace.net.au> Date: Sat, 03 Dec 2005 05:25:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050914 Debian/1.7.11-1 MIME-Version: 1.0 Cc: gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface References: <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> <20051203041402.GA24030@nevyn.them.org> <439122AF.5080606@netspace.net.au> <20051203044939.GA24620@nevyn.them.org> In-Reply-To: <20051203044939.GA24620@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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/msg00029.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 03:44:31PM +1100, Russell Shaw wrote: > >>>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... >> >>Looking at gdb docs, i couldn't find any "monitor" command or in the index. >> >>(gdb) help monitor >> >> Send a command to the remote monitor (remote targets only). > > Found `monitor' in Index. (`,' tries to find next.) > > `monitor CMD' > This command allows you to send commands directly to the remote > monitor. > >>Not very helpful. > > That's because the bits that go after the word "monitor" depend on your > target :-) > >>Anyway, preceding every command with "monitor" is hardly a nice or intuitive >>user interface. > > Of course. Provide a GDB script file that uses "define" to give things > pretty names, for example. It would be useful if the manual actually said that this is the way to add new commands for an external monitor. It is bad when i can only learn new things about gdb by complaining. >>>As for the state of GDB, that's a separate thread, and making progress >>>already. >> >>If there was an api for hardware-specific protocols, not only would >>performance of these improve, but there would be new developers >>seeing gdb code and having an interest in maintaining and improving >>it (i was really the first example). What's more, all kinds of >>unsupported debugger hardware could be added by users. Because each >>hardware goes into its own subdirectory, it doesn't complicate any >>other area of gdb and can be easily removed. That's how the backend >>of gcc works. > > I'm not convinced that performance is an issue here. I'd need numbers. > The total data transfer over the remote protocol is, usually, very > small - even if you're doing application downloads, it's just a couple > of extra buffer copies on the local system. If you expect to be > transfering huge data sessions, use a local pipe or fifo to connect to > the daemon instead of TCP. > >>A problem with the current method of using shims is that if you want >>to develop one, you have to go out and find one on the net to find a >>place to start. >> >>With all the interfaces in gdb subdirectories, all the example code that >>anyone could ever want for adding support for new hardware, is already >>there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one). > > If you wanted to add a skeleton protocol conversion daemon to the GDB > source tree, especially under the GPL, I'm sure we'd be glad to include > it! > > The problem with "remote*.c" is that most of them haven't been used in > years. Many of them are bad examples, or simply broken. I suppose i could start the shim daemon from a .gdbinit file using the gdb "shell" command. An explanation about shims and how to implement them in a way that is non-tedious to use, should be in the manual. Last time i read the remote protocol spec in the gdb manual, most of it was too terse to be useable.