Re: Library interface to GDB

Re: Library interface to GDB

[Brendan Simon]

It would be nice to write a GDB GUI with a cross platform toolkit such as
WxWindows.  WxWindows is an GUI API (C++ framework) and can be compiled to use
Motif, GTK, Qt, MSW and other Widget toolktis.  This way we can have naitvive
versions of the GDB GUI running on Linux, Windows, Unix, etc.

Brendan Simon.


Ovidiu Predescu wrote:

> On 27 May 1999 23:12:52 +0200, Martin Baulig <martin@home-of-linux.org> wrote:
>
> > Basically I want to write a GNOME frontend for gdb, but not just
> > "yet another gdb frontend", but *the* gdb frontend. Ideally it should
> > export all its functionallity through CORBA so you can also use it in
> > other projects like GNU Emacs, KDE or whatever.
>
> WDB, the HP supported version of GDB, already has a Corba interface and a GUI
> interface that uses it. You can download the sources and/or binaries from:
>
> http://www.hp.com/esy/lang/tools/Debuggers/WDB/index.html
>
> The sources for the Corba interface are under GPL and you can modify them to
> work with gdb 4.18 relatively easy.
>
> Best regards,
> --
> Ovidiu Predescu <ovidiu@cup.hp.com>
> http://www.geocities.com/SiliconValley/Monitor/7464/

Re: Library interface to GDB

[J.T. Conklin]

>>>>> "Todd" == Todd Whitesel <toddpw@wrs.com> writes:
Todd> Agreed. I've worked on debugger products that parsed the output
Todd> of the HP In-Circuit emulators' terminal interface, and it's a
Todd> losing battle.

Todd> HP themselves tried to write a gasket that would API-ify the
Todd> emulators, so that client programs would not have to deal with
Todd> the emulator output.  This was cancelled after a couple years.

>> A debugger GUI should use an API, not AI. :)

Todd> API yes, but not necessarily function calls.

Todd> I rather like the idea of a "protocol" command in GDB whose
Todd> subcommands produce machine-readable output.

Regardless of whether the GDB API is implemented by traditional
function-calls; a wrapper layer that interacts with the existing CLI;
a machine parsable protocol; or some other RPC mechanism, I believe a
more fundemental question remains: what level of abstraction will the
API present.  After that question is resolved, we can discuss what the
specific calls will be and how the API will be implemented.

I think that we would want a fairly high level of abstraction, but
perhaps much less than what is currently provided by the CLI.  It is
my impression that systems that sit atop GDB and interact via the CLI
sometimes must do a lot of work to do simple things.  Perhaps someone
who has actually worked on/with such interfaces can share their
experiences?

One way to start might be to start breaking down the things that GDB
does into broad categories.  Once that list is complete, we could
refine and layer those categories into a heirarchy.  In the end, I
think we'd have the raw information necessary to make design
decisions.

For example:

Memory Operations
	read memory @ address w/<operand width>
	write memory @ address

Register Operations
	read register
	write register

Symbol Operations
	read symbol file
	convert address to symbol
	convert symbol to address

Execution Options
	next
	ni
	step
	si
	continue

Breakpoint Options
	create breakpoint
	delete breakpoint
	enable breakpoint
	disable breakpoint

...

This is just a sample I whipped out off the top of my head.  Going
through the code, the documentation, etc. would yeild a more complete
list.

I'm not sure I have enough time to spearhead such a effort, but it
seems that a lot of these categories could be taken on independently
or in small groups.  As a result, it shouldn't take that long to put
something together...

	--jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Thu Jun 10 17:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: New stream - gdb_stdlog/gdb_stddebug?
Date: Thu, 10 Jun 1999 17:15:00 -0000
Message-id: <376053FF.3050D846@cygnus.com>
X-SW-Source: 1999-q2/msg00154.html
Content-length: 492

Hello,

At present GDB has two output streams:

	gdb_stdout
	gdb_stderr

I'd like to propose the addition of a third stream:

	gdb_stdlog OR gdb_stddebug

that would be used by any debug/log messages.

At present debug information is somewhat arbitrarily sent to either the
stdout or the stderr stream.  The intention here is to rationalize this
so that it is clear where any (non output) messages should go.

Anyone see any problems with this?  Any better names?

	Andrew
From ac131313@cygnus.com Thu Jun 10 17:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: New option? --trascript=FILE
Date: Thu, 10 Jun 1999 17:15:00 -0000
Message-id: <376052AA.A66D599F@cygnus.com>
X-SW-Source: 1999-q2/msg00153.html
Content-length: 1130

Hello,

I'd like to propose a new option ``--transcript=FILE'' that records all
user interface interactions that occure when GDB is running.

The format of the file would be:

	<line> ::= <command> | <output>
	<command> ::= a complete command ready to feed into the CLI
	<output> ::= "#" text...

for instance:

	$  gdb --transcript=LOG
	.....
	(gdb) target sim
	Connected to the simulator
	(gdb) load
	File loaded
	(gdb) break main
	Breakpoint ...
	(gdb) run
	main.c:main() reached
	(gdb) quit
	$ 

would create:

	target sim
	#Connected to the simulator
	load
	#File loaded
	break main
	#Breakpoint ...
	run
	#main.c:main() reached
	quit

which would then in turn allow:

	$  gdb -nx -x LOG
	.....
	Connected to the simulator
	File loaded
	Breakpoint ...
	main.c:main() reached
	$ 

Apart from the general idea.  Does anyone object to the choice of option
name?  Down the track we can see about commands that can control this.

	Andrew

PS: If you look carefully, I've omitted a detail - the ``quit'' should
prompt the user.  That wouldn't appear in the transcript any way.
From ac131313@cygnus.com Sat Jun 12 18:45:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: New stream - gdb_stdlog/gdb_stddebug?
Date: Sat, 12 Jun 1999 18:45:00 -0000
Message-id: <376309F8.333D404D@cygnus.com>
References: <376053FF.3050D846@cygnus.com>
X-SW-Source: 1999-q2/msg00155.html
Content-length: 639

Andrew Cagney wrote:
> 
> Hello,
> 
> At present GDB has two output streams:
> 
>         gdb_stdout
>         gdb_stderr
> 
> I'd like to propose the addition of a third stream:
> 
>         gdb_stdlog OR gdb_stddebug
> 
> that would be used by any debug/log messages.

For the moment I've called it ``gdb_stdlog'' and added it to main.c  At
the same time I've updated (fixed I would argue :-) remote.c and
gdbarch.c so that they send their trace/log messages to gdb_stdlog and
not gdb_stdout.

By default gdb_stdlog ends up in gdb_stdout so the TUI and normal users
won't notice any difference.

	enjoy,
		Andrew
From robertl@sco.com Sat Jun 12 20:59:00 1999
From: Robert Lipe <robertl@sco.com>
To: gdb@sourceware.cygnus.com
Subject: dwarf-2 problem on cc1
Date: Sat, 12 Jun 1999 20:59:00 -0000
Message-id: <19990612225533.A22838@rjlhome.sco.com>
X-SW-Source: 1999-q2/msg00156.html
Content-length: 3019

   ----- Transcript of session follows -----
550 gdb@gdb.cygnus.com... Host unknown (Name server: gdb.cygnus.com.: host not found)


[ Damned inconsistencies ] 

Date: Sat, 12 Jun 1999 20:00:46 -0500
From: Robert Lipe <robertl@sco.com>
To: egcs@egcs.cygnus.com
Cc: gdb@gdb.cygnus.com
Subject: dwarf-2 problem on cc1
Message-ID: <19990612200046.A22605@rjlhome.sco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95us

[ Two disparate groups copied; please drop the other as appropriate. ] 

I can't tell if this is an GCC problem or a GDB problem.   I'm inclined
to think it's EGCS becuase SCO's 'debug' complains about the binary, too.

I'm looking at GCC 2.95 (i686-UnixWare7.1.0-sysv5) with GDB 4.18.  Small
binaries work OK.   Big ones fail and I need help understanding why.

The easiest way to see this fail is in GCC itself after a full three-stage:

(robertl) rjludi:/home3/negcs/gcc
$ gdb ./cc1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-UnixWare7.1.0-sysv5"...

Dwarf Error: bad offset (0x93000200) in compilation unit header (offset 0x2320b5 + 6).

.gdbinit:8: Error in sourced command file:


Now, if I use GDB on GDB to debug cc1 and set breakpoints on this error,
I can see that it's not anything as "obvious" as a sign extension
problem.

(top-gdb) print /x cu_header
$2 = {length = 0x28000000, version = 0x2, abbrev_offset = 0x93000200, 
  addr_size = 0xce}

That's a pretty bogus looking length.




If I feed that same binary to the SCO dwarf-2 debugger, it complains in 
a different way:

$ debug cc1
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unimplemented DWARFII location operator at offset 0x5237: DW_OP_fbreg
Error: Unimplemented DWARFII debugging information entry in section .debug_info
New program cc1 (process p1) created


It's not strictly size related.   I can invoke gdb on cc1plus and it's 
fine.   gdb on several of the gen* programs and it's fine.   but the inability
to debug cc1 worries me.

Any ideas?

RJL



----- End forwarded message -----


----- End forwarded message -----
From robertl@sco.com Sat Jun 12 21:49:00 1999
From: Robert Lipe <robertl@sco.com>
To: egcs@egcs.cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: dwarf-2 problem on cc1
Date: Sat, 12 Jun 1999 21:49:00 -0000
Message-id: <19990612234841.A22906@rjlhome.sco.com>
References: <19990612200046.A22605@rjlhome.sco.com> <19990612200046.A22605@rjlhome.sco.com>
X-SW-Source: 1999-q2/msg00157.html
Content-length: 1707

> I can't tell if this is an GCC problem or a GDB problem.   I'm inclined
> to think it's EGCS becuase SCO's 'debug' complains about the binary, too.

GDB now seems to be off the hook here.

> This GDB was configured as "i686-UnixWare7.1.0-sysv5"...
>                                                                               > Dwarf Error: bad offset (0x93000200) in compilation unit header 
> (offset 0x2320b5 + 6).                                                                        
The problem seems to be one of mixing UDK dot-oh's with EGCS ones.
During the bootstrap the native compiler is used to build libiberty.
All of the "offending" objects that I could find were in the libiberty
directory. [ At one point, didn't we change the EGCS bootstrap to
rebuild libiberty? ]

Sure enough, if I blast libiberty and rebuild it with the freshly built
GCC, and relink cc1 with that libiberty this issue goes away.

It looks like someone still building configure's with an old version of
autoconf that doesn't have the fix that rth donated earlier this year.
So the libiberty that's being built has several .o's in it (like 'memset'
and 'memcpy') that shouldn't even be there.

Why aren't we using the fixed autoconf to generate correct configure 
scripts?  I thought Ben got that fix into 2.13 but will check.

The issue about compatibility with the native compilers is, I suppose,
a completely different problem.  (And one of lesser interest than the
general "something is broken" case.)  I now feel much better about the
reliability of the dwarf generation and handling in EGCS and GDB for
2.95.

...now the issue of dwarf-1 or dwarf-2 even making it through a bootstrap
comes to light. :-)

RJL
From jtc@redback.com Mon Jun 14 16:14:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 16:14:00 -0000
Message-id: <5mzp222x5d.fsf@jtc.redbacknetworks.com>
References: <375D205F.F191C5@cygnus.com>
X-SW-Source: 1999-q2/msg00158.html
Content-length: 3179

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Have you considered what to do when there is a choice of
Andrew> software breakpoints?  Jim Ingham's pointed out to me that in
Andrew> the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might
Andrew> be 2 bytes or 4 bytes in size (and the value different in each
Andrew> case).

I was unaware processors with multiple software breakpoints existed.
I assume that the 2 byte breakpoint instructions have to be inserted
in "high-density" code segments and 4 byte breakpoints insns have to
be inserted in "low-density" segments.

We can almost get away without specifying breakpoint types.  Since in
most cases the stub is bound into the executable, thus can determine
whether the breakpoint is within a high or low density code segment.
However, this would not be suitable for applications like monitors
with a remote protocol front end, as those would not have any prior
knowledge of an arbitrary program's memory map.

I was hoping to avoid exposing implementation details of breakpoints
managed by this extension.  This was intended to provide flexibility
so that breakpoints could be implemented using mechanisms beyond what
might be present in the CPU alone.  For example, the stub could use a
trap insn of some type instead of the traditional breakpoint insn, or
use some hardware assistance (perhaps in a memory controller ASIC).
As a result, although implementations could be quite different, GDB
would neither know nor care.

Andrew> For such targets, always sending the length would be easiest.
Andrew> Can any one see problems with sending the length regardless?

I was considering the possibility of interpreting the length field of
software breakpoints so as to represent address ranges.  The converse,
a breakpoint that traps whenever the PC falls out of a range is
probably more useful though.

I'm also thinking of ideas of how to do more breakpoint processing in
the stub.  The obvious thing is thread specific breakpoints --- it is
very inefficent for the target to stop and return control to GDB, for
GDB to query the current thread and determine that the breakpoint is
not appropriate, and then for GDB to continue execution.  If the stub
could determine the whether the breakpoint had really tripped,
performance would be much improved.  

In fact, GDB may not need to be modified significantly.  Since the
breakpoint has fired and program state is going to be examined (either
interactively or via a breakpoint command script), overhead of (re-)
confirming that the breakpoint is either global or for the current
thread should be negligable.  This would also allow for "thinner" stub
implement- ations that don't contain per-thread management of
breakpoints if code size is more important than performance.

Similarly, a simple (stack based?) scheme for evaluating conditional
breakpoints could be created, although I suspect this would require
significant changes to GDB internals.  It might be useful to nail down
(or at least think about) this even if it won't be implemented in the
near term, so it can be cleanly added to the protocol.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Mon Jun 14 16:35:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 16:35:00 -0000
Message-id: <3765916E.2D458BAF@cygnus.com>
References: <375D205F.F191C5@cygnus.com> <5mzp222x5d.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q2/msg00159.html
Content-length: 1469

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> Have you considered what to do when there is a choice of
> Andrew> software breakpoints?  Jim Ingham's pointed out to me that in
> Andrew> the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might
> Andrew> be 2 bytes or 4 bytes in size (and the value different in each
> Andrew> case).
> 
> I was unaware processors with multiple software breakpoints existed.
> I assume that the 2 byte breakpoint instructions have to be inserted
> in "high-density" code segments and 4 byte breakpoints insns have to
> be inserted in "low-density" segments.
> 
> We can almost get away without specifying breakpoint types.  Since in
> most cases the stub is bound into the executable, thus can determine
> whether the breakpoint is within a high or low density code segment.
> However, this would not be suitable for applications like monitors
> with a remote protocol front end, as those would not have any prior
> knowledge of an arbitrary program's memory map.

FYI,  I can't see how a stub can determine the breakpoint size/type from
just the address.  As it is GDB has enough trouble - in the case of the
ARM, GDB ends up using symbol table information.

I've also been doing some research into the ``B'' and ``b'' packets.
While the stubs found in gdb/*stub.c don't support ``b'' or any other
``B'' packet there are other stubs (non GPL'd) that do reconize it :-(

	Andrew
From sethnaz@sg.adi-limited.com.au Mon Jun 14 16:47:00 1999
From: Zubin Burjor Sethna <sethnaz@sg.adi-limited.com.au>
To: gdb@sourceware.cygnus.com
Subject: gdb + wiggler
Date: Mon, 14 Jun 1999 16:47:00 -0000
Message-id: <6006B52C37ABD211AB0900805FFE9D7916933C@exchange.sg.adisys.com.au>
X-SW-Source: 1999-q2/msg00160.html
Content-length: 323

Hi

Has anyone had any success using the gdb from the ecos tool chain with a
wiggler? A wiggler is a debugging interface for BDM and the target I am
using is MPC860? I tried the wiggler support in the ecos gdb but all I got
were core dumps. Do I need any additonal drivers than what is supplied with
gdb?


Thanks


Zubin

Library interface to GDB

[Martin Baulig]

Hello guys,

I want to write a library interface to GDB and I'd like to ask you some
questions and also get some feedback first.

The gdb source code (4.18) contains a file gdb/doc/libgdb.texi which has
been last modified in November 1993. This libgdb ist last mentioned in the
ChangeLogs in 1994/95. In the internals manual I finally found a note that
this "project" was aborted. On the other hand, I still find some references
to it at least the Makefile.in, but I remember having seen something about
it in the code itself.

What is the current status for libgdb, is it still supported or already
removed or whatever ... ?

Basically I want to write a GNOME frontend for gdb, but not just
"yet another gdb frontend", but *the* gdb frontend. Ideally it should
export all its functionallity through CORBA so you can also use it in
other projects like GNU Emacs, KDE or whatever.

For me, gdb ist part of the GNU project and I think it is important to
have some kind of "standard" library (or ideally CORBA, but that can also
be handled by the GNOME part) interface for it. Such an interface should
not be specific to any special window system but be usable in any graphical
gdb frontend.

It's no problem for me to actually write the code, but I'd like to get some
feedback first - and I'm open to any suggestions ...

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org
From tromey@cygnus.com Thu May 27 15:00:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Thu, 27 May 1999 15:00:00 -0000
Message-id: <87ogj6uqq1.fsf@cygnus.com>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00116.html
Content-length: 850

>>>>> "Martin" == Martin Baulig <martin@home-of-linux.org> writes:

I don't know the answers to your gdb questions.

Martin> Basically I want to write a GNOME frontend for gdb, but not
Martin> just "yet another gdb frontend", but *the* gdb
Martin> frontend. Ideally it should export all its functionallity
Martin> through CORBA so you can also use it in other projects like
Martin> GNU Emacs, KDE or whatever.

Are you familiar with dryad?
The author is working on a library that can be used to communicate
with gdb.  He is also writing a CORBA interface to gdb.

I think it would make sense for these parts to be separate from the
actual GUI.  That way if you don't like his GUI for some reason you
can implement your own -- but without reinventing the useful
GUI-independent pieces.

dryad is in the Gnome CVS repository.

Tom
From campd@oit.edu Thu May 27 15:17:00 1999
From: Dave Camp <campd@oit.edu>
To: tromey@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Thu, 27 May 1999 15:17:00 -0000
Message-id: <w53pv3mnoor.fsf@mystra.davec.dhs.org>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <87ogj6uqq1.fsf@cygnus.com>
X-SW-Source: 1999-q2/msg00117.html
Content-length: 2386

Tom Tromey <tromey@cygnus.com> writes:

> >>>>> "Martin" == Martin Baulig <martin@home-of-linux.org> writes:
> Martin> Basically I want to write a GNOME frontend for gdb, but not
> Martin> just "yet another gdb frontend", but *the* gdb
> Martin> frontend. Ideally it should export all its functionallity
> Martin> through CORBA so you can also use it in other projects like
> Martin> GNU Emacs, KDE or whatever.
> 
> Are you familiar with dryad?
> The author is working on a library that can be used to communicate
> with gdb.  He is also writing a CORBA interface to gdb.
Hi, I'm the author of Dryad, and I thought I'd clarify a little bit what the CORBA interface is.

The CORBA interface isn't intended exactly to be a CORBA interface to GDB, but more of a generic 'Debugger' interface.  In addition, the general idea of that interface (which is in the Corba module 'VDE' for 'Visual Development Environment') is that any particular GUI could implement it - whether or not that application uses GDB, or libdryad (the library that communicates with GDB).  This CORBA interface would perhaps include a 'show the locals window' method.

I am considering wrapping libdryad in a CORBA interface as well, to allow prospective GUIs to communicate with it via CORBA.  That would be a bit more like a CORBA interface to GDB.

> I think it would make sense for these parts to be separate from the
> actual GUI.  That way if you don't like his GUI for some reason you
> can implement your own -- but without reinventing the useful
> GUI-independent pieces.
Yes, that's basically what it does - the CORBA interface is just that; an interface.  Any debugger would be able to export the functionality, but the surrounding parts (Visual Development Environments utilizing the debugger, for example) would not necessarily know which debugger it was using.

Anyway, I'd just thought I'd clarify something that may have already been perfectly clear.  Thanks for your time,

-dave

And Martin - perhaps we can discuss working together on a debugger - taking some stuff from ggdb (for example, I like parts of the idl) and putting in Dryad, or whatever.  No sense in us working on redundant projects.  Email me and we'll discuss it.

-- 
Dave Camp             Student, Oregon Institute of Technology
campd@oit.edu         (541) 885-0261
http://davec.dhs.org  "Machines have no conscience" - Queensryche
From martin@home-of-linux.org Thu May 27 16:12:00 1999
From: Martin Baulig <martin@home-of-linux.org>
To: Dave Camp <campd@oit.edu>
Cc: tromey@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Thu, 27 May 1999 16:12:00 -0000
Message-id: <863e0i9key.fsf@localhost.uni-trier.de>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <87ogj6uqq1.fsf@cygnus.com> <w53pv3mnoor.fsf@mystra.davec.dhs.org>
X-SW-Source: 1999-q2/msg00118.html
Content-length: 1403

Dave Camp <campd@oit.edu> writes:

> And Martin - perhaps we can discuss working together on a debugger -
> taking some stuff from ggdb (for example, I like parts of the idl) and
> putting in Dryad, or whatever.  No sense in us working on redundant
> projects.  Email me and we'll discuss it.

Yes, sure. And my GDB library idea is not really a "redundant project",
it should be a very low-level interface to gdb which basically means to
put gdb into a library, export all important functions and add some
wrappers to things where gdb outputs text for instance.

If I understood your implementation correctly, your CORBA interface will
talk to libdryad which handles the interaction with the debugger but is
independent from any special debugger. This is a very good idea since it
gives people the chance to use dryad with a different debugger than gdb
as well.

I just want to insert an additional "layer of abstraction" - a low-level
interface to gdb which libdry will use so we'll have something like

    application (ie. dryad) ->                          ->  libgdb (for gdb)

                               dryad CORBA -> libdryad
                               
    other application       ->                          ->  libfoo (for bar)

Of cause we can discuss this, we really should work together on this project.

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org
From martin@home-of-linux.org Thu May 27 16:13:00 1999
From: Martin Baulig <martin@home-of-linux.org>
To: tromey@cygnus.com
Cc: gdb@sourceware.cygnus.com, campd@oit.edu
Subject: Re: Library interface to GDB
Date: Thu, 27 May 1999 16:13:00 -0000
Message-id: <86yaia85tw.fsf@localhost.uni-trier.de>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <87ogj6uqq1.fsf@cygnus.com>
X-SW-Source: 1999-q2/msg00119.html
Content-length: 1568

Tom Tromey <tromey@cygnus.com> writes:

> >>>>> "Martin" == Martin Baulig <martin@home-of-linux.org> writes:
> 
> I don't know the answers to your gdb questions.
> 
> Martin> Basically I want to write a GNOME frontend for gdb, but not
> Martin> just "yet another gdb frontend", but *the* gdb
> Martin> frontend. Ideally it should export all its functionallity
> Martin> through CORBA so you can also use it in other projects like
> Martin> GNU Emacs, KDE or whatever.
> 
> Are you familiar with dryad?
> The author is working on a library that can be used to communicate
> with gdb.  He is also writing a CORBA interface to gdb.

I haven't looked very closely at it yet, but it really looks good.

> I think it would make sense for these parts to be separate from the
> actual GUI.  That way if you don't like his GUI for some reason you
> can implement your own -- but without reinventing the useful
> GUI-independent pieces.

Yes, I agree. I like his GUI, but other people (for instance KDE folks)
may not like it and prefer using another.

The problem I see at the moment is that the only way to communicate with
gdb is to open a pipe and parse it's output. This affects xxgdb, dryad and
any other GUI.

This means that the first thing every author of any gdb GUI needs to do is
to write a parser. Such a parser is difficult to write, very inefficient and
it will always be buggy.

libgdb (Tom, you wrote it?) was already a good start to solve this problem,
but sure it has its problems.

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org
From tromey@cygnus.com Thu May 27 16:24:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: Martin Baulig <martin@home-of-linux.org>
Cc: gdb@sourceware.cygnus.com, campd@oit.edu
Subject: Re: Library interface to GDB
Date: Thu, 27 May 1999 16:24:00 -0000
Message-id: <87vhdet7td.fsf@cygnus.com>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <87ogj6uqq1.fsf@cygnus.com> <86yaia85tw.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00120.html
Content-length: 845

>>>>> "Martin" == Martin Baulig <martin@home-of-linux.org> writes:

Martin> The problem I see at the moment is that the only way to
Martin> communicate with gdb is to open a pipe and parse it's
Martin> output. This affects xxgdb, dryad and any other GUI.

Yes.

Gdbtk works by inserting its own code into gdb and running the
interface inside the gdb process.  This might be doable for other GUIs
as well, but it is probably painful as it means re-releasing gdb with
the GUI.

Martin> This means that the first thing every author of any gdb GUI
Martin> needs to do is to write a parser. Such a parser is difficult
Martin> to write, very inefficient and it will always be buggy.

I agree.

Martin> libgdb (Tom, you wrote it?) was already a good start to solve
Martin> this problem, but sure it has its problems.

Nope, I didn't write libgdb.

Tom
From ovidiu@cup.hp.com Thu May 27 16:36:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Martin Baulig <martin@home-of-linux.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB 
Date: Thu, 27 May 1999 16:36:00 -0000
Message-id: <199905272336.QAA03287@hpcll563.cup.hp.com>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00121.html
Content-length: 778

On 27 May 1999 23:12:52 +0200, Martin Baulig <martin@home-of-linux.org> wrote:

> Basically I want to write a GNOME frontend for gdb, but not just
> "yet another gdb frontend", but *the* gdb frontend. Ideally it should
> export all its functionallity through CORBA so you can also use it in
> other projects like GNU Emacs, KDE or whatever.

WDB, the HP supported version of GDB, already has a Corba interface and a GUI
interface that uses it. You can download the sources and/or binaries from:

http://www.hp.com/esy/lang/tools/Debuggers/WDB/index.html

The sources for the Corba interface are under GPL and you can modify them to
work with gdb 4.18 relatively easy.

Best regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/

Re: Library interface to GDB

[Andrew Cagney]

Martin Baulig wrote:

> 
> The gdb source code (4.18) contains a file gdb/doc/libgdb.texi which has
> been last modified in November 1993. This libgdb ist last mentioned in the
> ChangeLogs in 1994/95. In the internals manual I finally found a note that
> this "project" was aborted. On the other hand, I still find some references
> to it at least the Makefile.in, but I remember having seen something about
> it in the code itself.


Yes, if you look carefully at the code you'll probably notice many
things that have been structured in strange or mysterious ways.  I just
deleted several of them (the functions in question were empty):

Tue May 25 15:20:58 1999  Andrew Cagney  <cagney@amy.cygnus.com>

        * main.c (init_proc, proc_remove_foreign): Delete function.
        * inftarg.c (child_mourn_inferior): Update. Delete call to
        proc_remove_foreign().
        * top.c (gdb_init): Update. Delete call to init_proc().

My understanding (third hand?) is that at the time (back in '94/95)
libgdb proved to be one of those `good ideas'.  The sort of thing that
sounds good after one too many drinks :-)  What did come from it,
though, was a number of goals that would allow GDB to evolve into a more
powerful architecture better suited for things like GUI's.

To give a real example:

Elena, Stan (and many others) have just released the re-worked GDB that
includes an event loop (it is often referred to as async).  An event
loop is the sort of basic infrastructure needed in a debugger if it is
ever going to function correctly within a GUI or be embedded in a
library.  Without it, when blocked waiting for a target, the debugger
_IGNORES_ all other input sources (such as its CORBA interface).

As a testament to the quality of this work, it was completed in a way
that allows GDB to continue to function on all the existing
host-X-target combinations.

It would be interesting to know how many of the ``libgdb''
implementations people have so far put forward actually addressed this
fairly fundamental technical issue.


> What is the current status for libgdb, is it still supported or already
> removed or whatever ... ?


That project, as you note, was aborted long ago.  Many people have,
however, set out and achieved similar goals with varying degrees of
success.


> Basically I want to write a GNOME frontend for gdb, but not just
> "yet another gdb frontend", but *the* gdb frontend. Ideally it should
> export all its functionallity through CORBA so you can also use it in
> other projects like GNU Emacs, KDE or whatever.


With respect to CORBA, I see that one person mentioned that they had
implemented an interface by coding a parser of GDB's output.  To me,
this sounds like taking things in the wrong direction.  It is the sort
of solution used when talking to an unchanging legacy system.  GDB,
while old, is neither un-changing nor legacy :-)  GDB's  CLI is
definitely going to continue to evolve.

If there is going to an interface added to GDB then I think that it
should be implemented in a way that lends its self to maintainability
over a longer time frame.  While a CORBA interface is flavor of the
month, I believe that other people have different (although potentially
related) ideas. RMS, for instance, has pointed out that GDB should have
an interface that allowed scheme/guile to be integrated (as the official
scripting language).

(I like others have further thoughts on this but this e-mail is a big
enough chunk for now :-)

	enjoy,
		Andrew
From ac131313@cygnus.com Fri May 28 00:28:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: GDB meeting, Silicon Valley 1999-05-14
Date: Fri, 28 May 1999 00:28:00 -0000
Message-id: <374E4596.46F09793@cygnus.com>
References: <199905110256.TAA08098@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00125.html
Content-length: 1704

Stan Shebs wrote:
> If you can't make it, I expect that we will post a
> summary of the meeting afterwards.

Stan is away on holidays.

I thought I posted the below several days ago, but unfortunately, it is
now looking like it didn't go out :-(

The below was drafted by Stan.  I've since edited it slightly and am now
posting it.

	sorry for the delay,
		Andrew

--

Last Friday (1999-05-14) a group of GDB hackers and other
interested parties got together to discuss the maintenance
of GDB.  The meeting was held at HP's Cupertino CA campus,
and included the following participants:

       Andrew Cagney (cagney@cygnus.com)
       J. T. Conklin (jtc@redbacknetworks.com)
       Robert Dewar (dewar@gnat.com)
       Klee Dienes (klee@apple.com)
       Wes Embry (wes@sgi.com)
       Paul Hilfinger (hilfingr@CS.Berkeley.edu)
       David Metcalfe (crdjm@sgi.com)
       Paul Sanville (sanville@flytrap.cup.hp.com)
       Stan Shebs (shebs@cygnus.com)
       Richard Stallman (rms@gnu.org)
       Mike Vermeulen (mev@cup.hp.com)
       Sanjay Waghray (sw@home.com)
       Todd Whitesel (toddpw@wrs.com)

Much of the discussion focussed on the technical directions
that have been discussed in this forum already (multi-architecture,
multi-process, async debug).  There was also discussion of
using Guile with GTK to build the standard windowed interface
for GDB.

We did agree to form a "steering committee" for GDB.  This
committee (having a size and form similar to the existing GCC
committee) would focus on overall policy for GDB. Day-to-day
maintenance issues would generally continue as before.
Committee membership was not decided at this meeting, and will
be worked out in the coming weeks.

--
From martin@home-of-linux.org Fri May 28 01:32:00 1999
From: Martin Baulig <martin@home-of-linux.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Fri, 28 May 1999 01:32:00 -0000
Message-id: <86hfoxegy4.fsf@localhost.uni-trier.de>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <374E319F.54921BD7@cygnus.com>
X-SW-Source: 1999-q2/msg00126.html
Content-length: 902

Andrew Cagney <ac131313@cygnus.com> writes:

> If there is going to an interface added to GDB then I think that it
> should be implemented in a way that lends its self to maintainability
> over a longer time frame.  While a CORBA interface is flavor of the
> month, I believe that other people have different (although potentially
> related) ideas. RMS, for instance, has pointed out that GDB should have
> an interface that allowed scheme/guile to be integrated (as the official
> scripting language).

Yes, I agree. It's nice to have a CORBA interface for gdb, but that should
be separeted from the actual gdb distribution - this can for instance be
handled by applications like dryad.

However, a guile interface really sounds good - especially since this is
the official scripting language. Maybe I can give it a try ...

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org
From jkamdar@emc.com Fri May 28 07:38:00 1999
From: Jayesh Kamdar <jkamdar@emc.com>
To: Martin Baulig <martin@home-of-linux.org>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Fri, 28 May 1999 07:38:00 -0000
Message-id: <374EAA39.FCBEBB58@emc.com>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <374E319F.54921BD7@cygnus.com> <86hfoxegy4.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00127.html
Content-length: 1547

Sorry for the ignorance ( I am not a developer) but is COBRA an GUI
interface to GDB ?  Is it available on all platforms ?  And where can I
get it from ?  And also, then what is xxgdb, isn't it a GUI gdb ?

Thanks,
Jayesh

Martin Baulig wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > If there is going to an interface added to GDB then I think that it
> > should be implemented in a way that lends its self to maintainability
> > over a longer time frame.  While a CORBA interface is flavor of the
> > month, I believe that other people have different (although potentially
> > related) ideas. RMS, for instance, has pointed out that GDB should have
> > an interface that allowed scheme/guile to be integrated (as the official
> > scripting language).
> 
> Yes, I agree. It's nice to have a CORBA interface for gdb, but that should
> be separeted from the actual gdb distribution - this can for instance be
> handled by applications like dryad.
> 
> However, a guile interface really sounds good - especially since this is
> the official scripting language. Maybe I can give it a try ...
> 
> --
> Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org

-- 
_________________________________________________________
    Contrary to popular belief, UNIX is user friendly.
It's just very particular about who it makes friends with
_________________________________________________________
Jayesh Kamdar (Email: jkamdar@emc.com)
EMC Corp.
171 South St., Hopkinton, MA 01748
Ph.: 800-445-2588 x2464  Fax: 508-435-8824
From ovidiu@cup.hp.com Fri May 28 09:04:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Martin Baulig <martin@home-of-linux.org>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB 
Date: Fri, 28 May 1999 09:04:00 -0000
Message-id: <199905281604.JAA12819@hpcll563.cup.hp.com>
References: <86hfoxegy4.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00128.html
Content-length: 2866

On 28 May 1999 10:28:35 +0200, Martin Baulig <martin@home-of-linux.org> wrote:

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > If there is going to an interface added to GDB then I think that it
> > should be implemented in a way that lends its self to maintainability
> > over a longer time frame.  While a CORBA interface is flavor of the
> > month, I believe that other people have different (although potentially
> > related) ideas. RMS, for instance, has pointed out that GDB should have
> > an interface that allowed scheme/guile to be integrated (as the official
> > scripting language).
> 
> Yes, I agree. It's nice to have a CORBA interface for gdb, but that should
> be separeted from the actual gdb distribution - this can for instance be
> handled by applications like dryad.
> 
> However, a guile interface really sounds good - especially since this is
> the official scripting language. Maybe I can give it a try ...

IMO libgdb should provide more than a simple interface to the gdb commands.
Ideally it should provide an object-oriented view of the GDB internal
structures. All the GDB structures that are used internally by GDB, frames,
symbols, values, breakpoints and so on, would become classes and would have
methods that operate on them.

If these objects are exported in a scripting language then writing extensions
would be very easy, since you have access to GDB's internals. For example you
could imagine an interface to the outside world that uses the HTTP protocol and
returns the data in an XML format. You could relatively easy build a graphical
user interface that's running in Netscape, just replace the output format of
the data to use HTML instead of XML. Or you can write a Corba interface that
exports these GDB objects or provides an API for building GUIs.

In the WDB project ( http://www.hp.com/esy/lang/tools/Debuggers/WDB/index.html )
we are working on integrating Python into GDB and exporting the GDB structures
as first class objects in it. Python ( http://www.python.org ) is an interpreted
object-oriented language with very powerful capabilities and rich libraries.

With this layer built on top of GDB, you can use a language bridge to export
the Python objects into other languages like Guile or Perl. The Python objects
would appear as native objects in these languages so you could send messages in
a transparent way from Perl or Guile to an object whose implementation is
written in Python. If the bridge is multi-directional, the other way are also
possible, invoking Guile or Perl methods from Python. Such an idea is already
implemented by the ILU project (see ftp://ftp.parc.xerox.com/pub/ilu/ilu.html ).

This way we basically give our users the language of their choice to implement
extensions.

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/

Re: Library interface to GDB

[Greg Watson]

Dave, Martin,

I too have been doing some work in this area that may be of interest. I've
developed a client/server debugger API using a combination of SunRPC and
Berkeley sockets that I guess falls somewhere between the CORBA/libgdb ideas
you've been discussing. My API is designed to interface directly with a UI/GUI
and is independent of the back-end debugger. Of course, I've also had to resort
to building a gdb command/response parser like the libdryad one. I've long
thought that it would be great to have a library interface to gdb commands, but
run into the same problems with libgdb as you've done. The architecure you
suggest below would fit extremely well into my project, so I'd be happy to be
involved in this as well.

Regards,

Greg Watson
Research Fellow
Monash University, Melbourne, Australia

Martin Baulig wrote:

> Dave Camp <campd@oit.edu> writes:
>
> > And Martin - perhaps we can discuss working together on a debugger -
> > taking some stuff from ggdb (for example, I like parts of the idl) and
> > putting in Dryad, or whatever.  No sense in us working on redundant
> > projects.  Email me and we'll discuss it.
>
> Yes, sure. And my GDB library idea is not really a "redundant project",
> it should be a very low-level interface to gdb which basically means to
> put gdb into a library, export all important functions and add some
> wrappers to things where gdb outputs text for instance.
>
> If I understood your implementation correctly, your CORBA interface will
> talk to libdryad which handles the interaction with the debugger but is
> independent from any special debugger. This is a very good idea since it
> gives people the chance to use dryad with a different debugger than gdb
> as well.
>
> I just want to insert an additional "layer of abstraction" - a low-level
> interface to gdb which libdry will use so we'll have something like
>
>     application (ie. dryad) ->                          ->  libgdb (for gdb)
>
>                                dryad CORBA -> libdryad
>
>     other application       ->                          ->  libfoo (for bar)
>
> Of cause we can discuss this, we really should work together on this project.
>
> --
> Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org

Re: Library interface to GDB

[Magdalena Sujecka]

Hello, 
I would like to know from what can I download Dryad? Does it work with
ORBacus ?
		Thank you 

			>>>>>	Magda Sujecka  <<<<< Ad epistulam novam >>>>> 

Re: Library interface to GDB

[Stan Shebs]

   From: Martin Baulig <martin@home-of-linux.org>
   Date: 27 May 1999 23:12:52 +0200

Hi, I'm just catching up with my mail.  It looks like everything has been
pretty well discussed already, so I'll throw in a couple extra points.

   The gdb source code (4.18) contains a file gdb/doc/libgdb.texi which has
   been last modified in November 1993. This libgdb ist last mentioned in the
   ChangeLogs in 1994/95. In the internals manual I finally found a note that
   this "project" was aborted. On the other hand, I still find some references
   to it at least the Makefile.in, but I remember having seen something about
   it in the code itself.

   What is the current status for libgdb, is it still supported or already
   removed or whatever ... ?

There were actually two projects that went on - one was Cygnus' first
attempt to build a GUI (which failed to produce anything usable and
was killed off), and then later Cygnus had a contract to enable GDB
to work as a component of a fancy parallel debugging system.  For both
of these "libgdb" was a nice-to-have, not a requirement, so you ended
up with the situation you see now, where things were started but not
finished.

So right now libgdb work is in limbo.  Since I figured it would
restart someday, I left the docs and other bits in, so people wouldn't
have to reinvent any wheels.  There seems to be a resurgence of
interest in adding different kinds of frontends to GDB, so this seems
like a good time to get moving on it again...

   Basically I want to write a GNOME frontend for gdb, but not just
   "yet another gdb frontend", but *the* gdb frontend. Ideally it should
   export all its functionallity through CORBA so you can also use it in
   other projects like GNU Emacs, KDE or whatever.

The GNU project would like to see somebody do the GDB + Guile + gtk +
Gnome combination, so if you work on that, you will have people
cheering you on.  An internal GDB API ("libgdb") is not a base
requirement for this, but to me is simply good software engineering -
since you will end up with both a command-line interface and a
compiled-in GUI, libgdb will be the result of factoring the code into
interface and debugger subsystems.

As for the design of the API, Ovidiu's message is a good discussion of
a key point, namely, that the API should be object-oriented.  Not in a
literal sense, since there needs to be a plain C implementation of it,
but logically, since GDB maintains large amounts of internal state,
and a reasonable API would be expressed in terms of operations on the
objects that make up that state.

								Stan
From shebs@cygnus.com Mon Jun 07 17:20:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com
Subject: Re: Debugging dynamically linked executables
Date: Mon, 07 Jun 1999 17:20:00 -0000
Message-id: <199906080020.RAA11496@andros.cygnus.com>
References: <199905081445.QAA06947@delius.kettenis.nl>
X-SW-Source: 1999-q2/msg00142.html
Content-length: 895

   Date: Sat, 8 May 1999 16:45:39 +0200 (CEST)
   From: Mark Kettenis <kettenis@wins.uva.nl>

   AFAICT it is not possible to make gdb stop at the first instruction
   that will be executed for a dynamically linked executable (which will
   probably be the first instruction of the dynamic linker).  

   [...]

   I was thinking about adding an option (suggested name
   stop-on-startup), so that people could say "set stop-on-startup 1".

   Would this be acceptable?

I read this, and got a sense of deja' vu (not dejagnu :-) ) about
having discussed this with Richard Henderson and Ulrich Drepper at
some point, in connection with debugging dynamic loaders...

In any case, the idea of a stop-on-startup option seems reasonable
to me.  Since it's not a normal user option, you would probably want
to put it into the "obscure" class, perhaps even make it a maintenance
command.

							Stan

Re: Library interface to GDB

[Brendan Simon]

Stan Shebs wrote:

> There were actually two projects that went on - one was Cygnus' first
> attempt to build a GUI (which failed to produce anything usable and
> was killed off), and then later Cygnus had a contract to enable GDB
> to work as a component of a fancy parallel debugging system.  For both
> of these "libgdb" was a nice-to-have, not a requirement, so you ended
> up with the situation you see now, where things were started but not
> finished.
>
> So right now libgdb work is in limbo.  Since I figured it would
> restart someday, I left the docs and other bits in, so people wouldn't
> have to reinvent any wheels.  There seems to be a resurgence of
> interest in adding different kinds of frontends to GDB, so this seems
> like a good time to get moving on it again...
>
>    Basically I want to write a GNOME frontend for gdb, but not just
>    "yet another gdb frontend", but *the* gdb frontend. Ideally it should
>    export all its functionallity through CORBA so you can also use it in
>    other projects like GNU Emacs, KDE or whatever.
>
> The GNU project would like to see somebody do the GDB + Guile + gtk +
> Gnome combination, so if you work on that, you will have people
> cheering you on.  An internal GDB API ("libgdb") is not a base
> requirement for this, but to me is simply good software engineering -
> since you will end up with both a command-line interface and a
> compiled-in GUI, libgdb will be the result of factoring the code into
> interface and debugger subsystems.
>
> As for the design of the API, Ovidiu's message is a good discussion of
> a key point, namely, that the API should be object-oriented.  Not in a
> literal sense, since there needs to be a plain C implementation of it,
> but logically, since GDB maintains large amounts of internal state,
> and a reasonable API would be expressed in terms of operations on the
> objects that make up that state.

How do other GUIs (DDD, VIDE, etc) currently interface with GDB ?
Through a library interface (shared or static) ?
Through operating system inter-process communications ?
By faking user input command lines ?
Some other means which is beyond my limited mind to think of ?

I would have thougt that libgdb would be the obvious choice but if it has been in
limbo for a while then there must be another method.

Brendan Simon.

Re: Library interface to GDB

[Stan Shebs]

   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.