Re: Library interface to GDB

[Stan Shebs <shebs@cygnus.com>]

   Date: Tue, 08 Jun 1999 00:36:37 +0000
   From: Brendan Simon <brendan@dgs.monash.edu.au>

   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 <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com, "J.T. Conklin" <jtc@redbacknetworks.com>
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<type>,<address>[,<length>]
> 
>         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 <jimb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
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: <nphfoi66s2.fsf@zwingli.cygnus.com>
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 <robertl@sco.com>
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: <nphfoi66s2.fsf@zwingli.cygnus.com>
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 <ac131313@cygnus.com>
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 <auug-announce@auug.org.au>.
To unsubscribe from this list, send a message to <majordomo@auug.org.au>
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 <martin@home-of-linux.org>
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 <brendan@dgs.monash.edu.au>
To: gdb <gdb@sourceware.cygnus.com>
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.