Re: Library interface to GDB

[jtc@redback.com (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