From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: brendan@dgs.monash.edu.au Cc: gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Mon, 07 Jun 1999 17:49:00 -0000 Message-id: <199906080049.RAA11560@andros.cygnus.com> References: <375C6594.289E0D94@dgs.monash.edu.au> X-SW-Source: 1999-q2/msg00144.html Date: Tue, 08 Jun 1999 00:36:37 +0000 From: Brendan Simon How do other GUIs (DDD, VIDE, etc) currently interface with GDB ? Usually by running GDB as a subprocess and controlling all the command input and output. This works better than one might imagine, since the GDB commands were specified on the back of the stone tablets that Moses brought down from Mt Sinai, and thus don't change often :-), and the output has a fairly consistent form as well. On the other hand, as someone commented, you do have to do some parsing work, and there is no guarantee that the command interface won't change in some way that is deemed helpful for users, but confuses the GUI. Stan >From ac131313@cygnus.com Tue Jun 08 06:54:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com, "J.T. Conklin" Subject: Re: breakpoint extension for remote protocol, take II Date: Tue, 08 Jun 1999 06:54:00 -0000 Message-id: <375D205F.F191C5@cygnus.com> X-SW-Source: 1999-q2/msg00145.html Content-length: 717 > I've had some time to refine my break/watchpoint extensions, and have > come up with this revised proposal. > > Request Packet > > insert break B,
[,] > > reply OK for success. > ENN for an error. > > J.T. Have you considered what to do when there is a choice of software breakpoints? Jim Ingham's pointed out to me that in the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might be 2 bytes or 4 bytes in size (and the value different in each case). For such targets, always sending the length would be easiest. Can any one see problems with sending the length regardless? enjoy, Andrew >From jimb@cygnus.com Tue Jun 08 08:39:00 1999 From: Jim Blandy To: Stan Shebs Cc: brendan@dgs.monash.edu.au, gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Tue, 08 Jun 1999 08:39:00 -0000 Message-id: References: <199906080049.RAA11560@andros.cygnus.com> X-SW-Source: 1999-q2/msg00146.html Content-length: 1421 > How do other GUIs (DDD, VIDE, etc) currently interface with GDB ? > > Usually by running GDB as a subprocess and controlling all the command > input and output. This works better than one might imagine, since the > GDB commands were specified on the back of the stone tablets that > Moses brought down from Mt Sinai, and thus don't change often :-), and > the output has a fairly consistent form as well. For what it's worth: I haven't actually had great experiences with this. Once I tried to browse a Binary File Descriptor with DDD, and it choked on the structure, treating the last few dozen members as one big long member with lots of commas. I didn't debug it, but it looked pretty clearly like a parsing problem. I've run into similar problems trying to use GDBTk with a simulator --- GDB didn't produce quite what GDBTk was expecting, so GDBTk hung. If I remember correctly, Jim Ingham (tech lead for GDBTk) has also said that he has found the approach to be unreliable. I think that interfaces based on parsing are generally not robust. The small-scale problem is solveable --- it's not difficult to make each piece of output GDB produces parseable --- but the large-scale problem of knowing all the messages GDB could possibly produce at a certain point is very difficult. I think it's really bad news to have code parsing output intended for humans. A debugger GUI should use an API, not AI. :) >From robertl@sco.com Tue Jun 08 10:55:00 1999 From: Robert Lipe To: gdb@sourceware.cygnus.com Subject: [daemon@cygnus.com: Re: Problems with [linux] gdb 4.18 and threads...] Date: Tue, 08 Jun 1999 10:55:00 -0000 Message-id: <19990608125459.B3766@rjlhome.sco.com> X-SW-Source: 1999-q2/msg00147.html Content-length: 644 > GDB 4.18, as released by Cygnus, does not support LinuxThreads. The > random signals are the threads trying to communicate with each other. > > The GDB packages included in most distributions (including Red Hat > 5.2) include patches that add LinuxThreads support to GDB. FWIW, the GDB that ships with RH6.0/x86 does seem to contain functional support for threads. RH6.0/Sparc's support seems to be broken: Alloc daemon started. Program received signal ?, Unknown signal. 0x5006f1c0 in __syscall_rt_sigsuspend () at soinit.c:59 soinit.c:59: No such file or directory. (gdb) Yes, this is a real drag. ----- End forwarded message ----- >From toddpw@wrs.com Tue Jun 08 16:53:00 1999 From: toddpw@wrs.com (Todd Whitesel) To: jimb@cygnus.com (Jim Blandy) Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: Library interface to GDB Date: Tue, 08 Jun 1999 16:53:00 -0000 Message-id: <199906082353.QAA23739@alabama.wrs.com> References: X-SW-Source: 1999-q2/msg00148.html Content-length: 1439 > I think it's really bad news to have code parsing output intended for > humans. Agreed. I've worked on debugger products that parsed the output of the HP In-Circuit emulators' terminal interface, and it's a losing battle. HP themselves tried to write a gasket that would API-ify the emulators, so that client programs would not have to deal with the emulator output. This was cancelled after a couple years. > A debugger GUI should use an API, not AI. :) API yes, but not necessarily function calls. I rather like the idea of a "protocol" command in GDB whose subcommands produce machine-readable output. The API to GDB basically takes two forms: - send a character to feed to readline for a command-line session (currently only one, but there's no fundamental reason why readline and the command logic couldn't be made instantiable with each instance getting its own value history and thread settings and so on). - send complete command string to be executed in a separate I/O context so that the output can be returned. This might need environment info like the thread ID and such. It wouldn't be hard to add a GDB option that creates a socket connection to another process, and accepts input over it. There would have to be a simple wrapper format so that the various channels (key input, command input, stdout, error(), warning(), protocol output, etc) could be distinguished. -- Todd Whitesel toddpw @ wrs.com >From ac131313@cygnus.com Wed Jun 09 21:38:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Australian Open Source Symposium, Melbourne, Australia Date: Wed, 09 Jun 1999 21:38:00 -0000 Message-id: <375F410D.96335E3D@cygnus.com> X-SW-Source: 1999-q2/msg00149.html Content-length: 3039 FYI, Australian Open Source Symposium, Melbourne, Australia I'm one of the speakers and will be giving a brief presentation on GDB. enjoy, Andrew -- Andrew Cagney Cygnus Solutions -- Sent by michael.paddon@auug.org.au to . To unsubscribe from this list, send a message to with the line "unsubscribe auug-announce" in the message body. Dear Colleague, It is just two weeks to the 1st Australian Open Source Symposium. This event, by developers and for developers, is a great opportunity to come along and meet other members of the local open source community. As you can see, we have lined up a strong and interesting set of speakers, on a wide variety of open source topics, who will help make the day informative as well as enjoyable. This is also a great chance for you to come along and find support, help and developers for your own pet open source project. Finally, as the first event of this type in Australia, we need your support. Please consider coming along, and be part of bootstrapping open source development in this country. Hope to see you there, The AOSS committee AOSS 1 is proudly supported by AUUG Inc, ISOC-AU, Linux Users Victora and SAGE-AU. Details: When? June 16, 1999 Where? 380 St Kilda Rd, Melbourne How much? $60 per head, (includes morning tea, lunch and afternoon tea) Watch the www.auug.org.au website for more information. Registration: Please fill in this form and email or fax it to us. Fax: (02) 9858-4926 Email: busmgr@auug.org.au If you prefer, you can register by phone. Phone: (02) 9858-4542 Name: ____________________________________________________ Organisation: ____________________________________________________ Email: ____________________________________________________ Please choose a payment method: ___ I will be paying by cash or cheque at the door. ___ I will be paying by credit card. Card Type: ___ Bankcard ___ MasterCard ___ Visa Card Number: _________________________________________ Name on Card: _________________________________________ Expiry Date: _________________________________________ I hereby authorise AUUG Inc to charge a fee of $60 to the above credit card. Signature: _________________________________________ Provisional Timetable 0900 Registration 1000 The Diary of an Open Source Project (Con Zymaris) 1030 GDB: The GNU Project Debugger (Andrew Cagney) 1100 Morning Tea 1130 Affordable Supercomputing - Parallel Processing with Linux (Rajkumar Buyya) 1200 Eddieware (Michael Rumsewicz) 1230 Lunch (1 hr) 1330 Colour in an Open World (Graeme Gill) 1400 Building RPMS (Richard Keech) 1430 To be confirmed 1500 Afternoon Tea 1530 Panel session 1600 Project pitches 1615 Close >From martin@home-of-linux.org Thu Jun 10 12:49:00 1999 From: Martin Baulig To: toddpw@wrs.com (Todd Whitesel) Cc: jimb@cygnus.com (Jim Blandy), gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: Library interface to GDB Date: Thu, 10 Jun 1999 12:49:00 -0000 Message-id: <86909rj0of.fsf@localhost.uni-trier.de> References: <199906082353.QAA23739@alabama.wrs.com> X-SW-Source: 1999-q2/msg00150.html Content-length: 1711 toddpw@wrs.com (Todd Whitesel) writes: > > I think it's really bad news to have code parsing output intended for > > humans. > > Agreed. I've worked on debugger products that parsed the output of the > HP In-Circuit emulators' terminal interface, and it's a losing battle. > > HP themselves tried to write a gasket that would API-ify the emulators, > so that client programs would not have to deal with the emulator output. > This was cancelled after a couple years. > > > A debugger GUI should use an API, not AI. :) > > API yes, but not necessarily function calls. > > I rather like the idea of a "protocol" command in GDB whose subcommands > produce machine-readable output. > > The API to GDB basically takes two forms: > - send a character to feed to readline for a command-line session > (currently only one, but there's no fundamental reason why readline > and the command logic couldn't be made instantiable with each instance > getting its own value history and thread settings and so on). > - send complete command string to be executed in a separate I/O context > so that the output can be returned. This might need environment info > like the thread ID and such. > > It wouldn't be hard to add a GDB option that creates a socket connection > to another process, and accepts input over it. There would have to be a > simple wrapper format so that the various channels (key input, command input, > stdout, error(), warning(), protocol output, etc) could be distinguished. I'd prefer a real function-call based API with real callbacks more (something like the guile interface I'm currently writing ...) -- Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org >From brendan@dgs.monash.edu.au Thu Jun 10 16:21:00 1999 From: Brendan Simon To: gdb Subject: Re: Library interface to GDB Date: Thu, 10 Jun 1999 16:21:00 -0000 Message-id: <376046DB.AD80089C@dgs.monash.edu.au> References: <199906082353.QAA23739@alabama.wrs.com> <86909rj0of.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q2/msg00151.html Content-length: 1218 > > I rather like the idea of a "protocol" command in GDB whose subcommands > > produce machine-readable output. > > > > The API to GDB basically takes two forms: > > - send a character to feed to readline for a command-line session > > (currently only one, but there's no fundamental reason why readline > > and the command logic couldn't be made instantiable with each instance > > getting its own value history and thread settings and so on). > > - send complete command string to be executed in a separate I/O context > > so that the output can be returned. This might need environment info > > like the thread ID and such. > > > > It wouldn't be hard to add a GDB option that creates a socket connection > > to another process, and accepts input over it. There would have to be a > > simple wrapper format so that the various channels (key input, command input, > > stdout, error(), warning(), protocol output, etc) could be distinguished. I thought along the same lines with respect to using sockets as the interface. ie. classic client/server approach. From what I know the gdbserver program is seperate to gdb. Maybe it could be integrated into gdb. Brendan Simon.