Re: Newlib, GDB Simulators, and Configurations

Re: Newlib, GDB Simulators, and Configurations

[Doug Evans]

   Date: Fri, 03 Sep 99 14:20:07 +0100
   From: Richard Black <rjb@dcs.gla.ac.uk>

   [ resending to sourceware addresses following bounce ]

   There currently doesn't seem to exist any 'libc' like thing for programs which 
   are going to be run under gdb's simulator to link against (distributed with 
   gdb).  It seems to be that using newlib would be the obvious candidate, and 
   I'll return to you any improvements that I make.

   I have looked at the newlib distribution and it seems that I'd need to add 
   into libgloss/ the "os" stuff necessary for basic reading and writing through 
   the gdb simulator.

   Currently libgloss/ doesn't support the Arm at all so I will have some config 
   hacking to do.

Actually, newlib has the necessary syscall stuff for arm programs to run
on the ARMulator.
[It use to be the case that this stuff lived in newlib.  Then, libgloss
was created to hold this stuff, but the arm port of newlib hasn't been
updated.]
From rjb@dcs.gla.ac.uk Fri Sep 03 09:16:00 1999
From: Richard Black <rjb@dcs.gla.ac.uk>
To: Doug Evans <devans@cygnus.com>
Cc: rjb@dcs.gla.ac.uk, newlib@sourceware.cygnus.com, gdb@sourceware.cygnus.com, rjb@dcs.gla.ac.uk
Subject: Re: Newlib, GDB Simulators, and Configurations 
Date: Fri, 03 Sep 1999 09:16:00 -0000
Message-id: <9909031615.AA31742@bathurst>
References: <199909031609.JAA19210@canuck.cygnus.com.>
X-SW-Source: 1999-q3/msg00291.html
Content-length: 314

Doug,

Indeed, I'm now building it and it seems to be going OK. Earlier the

*** This configuration is not supported in the following subdirectories:
     target-libgloss
    (Any other directories should still work fine.)

warning, plus another hidden problem were making me think otherwise.

Thanks,

Richard.

Re: Newlib, GDB Simulators, and Configurations

[Todd Whitesel]

> I'm wondering what this should be called. In this instance is gdb the hardware
> or the operating system or both?  What sort of config option should I be going

The simulator can run as a seperate program (it's actually called 'run') and
while the simulator's ABI may be derived directly from some specific O/S, it
probably doesn't support everything and deserves its own O/S name.

I like just 'sim', as in arm-sim-coff.

-- 
Todd Whitesel
toddpw @ wrs.com
From robbe@prosun.first.gmd.de Sun Sep 05 09:19:00 1999
From: Clemens Klein-Robbenhaar <robbe@prosun.first.gmd.de>
To: gdb@sourceware.cygnus.com
Subject: Re: Next release of GDB 
Date: Sun, 05 Sep 1999 09:19:00 -0000
Message-id: <199909051618.SAA01412@caracol.first.gmd.de>
X-SW-Source: 1999-q3/msg00293.html
Content-length: 1394

Stan Shebs wrote:

[...]
> Here are some additional things that I would like to see, but that
> ought not to hold up the release if they can't be gotten in:
>
> * first version of libgdb, w/Guile scripting
> * GNU/Linux thread_db library support
> * asynchronous execution for GNU/Linux
> * fork following for GNU/Linux
> * HP WDB 1.1 bits
> * Apple MacOS X support bits
> * Current VxWorks (Tornado) support bits
> * Current LynxOS support bits
> * m68k BDM patches
> * Ada language support
> 
> There are probably many other important things that I'm forgetting,
> please speak up and remind me about them!
[...]

... what about Objective C support? That should not be to hard.
(For gdb-4.16 and gdb-4.17, there was a patch,
afaik by Michael Snyder <msnyder@NeXT.com>;
still present at ftp://alpha.gnu.org/gnu/gnustep/contrib
This patch does not work for gdb-4.18, but only because the code
changed too much for the "patch" program to apply, I think.) 

Have I missed some point here -- has the Objective C patch
been rejected because of pricipal reasons not supporting Objective C
in gdb? As I scanned the archives, I found only 
Christopher Seawood <cls@seawood.org> 
http://sourceware.cygnus.com/ml/gdb-patches/1998/msg00115.html
raising the same issue, but without getting any feedback.
 
 Or has just nobody been around so far interested in doing the
(little) work?


regards, 
 clemens
From ac131313@cygnus.com Sun Sep 05 22:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Remote and CNTRL-C + X packet?
Date: Sun, 05 Sep 1999 22:50:00 -0000
Message-id: <37D35600.3502054A@cygnus.com>
X-SW-Source: 1999-q3/msg00294.html
Content-length: 465

Hello,

(Here's one for the remote-protocol police).
When GDB wants a remote target to stop it can either perform an
out-of-band ``break'' or send the CNTRL-C character.

Technically this makes a singe CNTRL-C a packet in its own right (arrg
:-). Should the protocol specify that a CNTRL-C is only valid outside of
other packets (such as X).  Should it be sent within a proper packet (I
suspect some existing targets would ignore it).

	slightly confused,
		Andrew
From ac131313@cygnus.com Mon Sep 06 00:39:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Ovidiu Predescu <ovidiu@cup.hp.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: libGDB architecture
Date: Mon, 06 Sep 1999 00:39:00 -0000
Message-id: <37D36E8A.3B05D73B@cygnus.com>
References: <199909010040.RAA11704@hpcll563.cup.hp.com>
X-SW-Source: 1999-q3/msg00295.html
Content-length: 7476

Ovidiu Predescu wrote:
> 
> Hi,
> 
> Sorry for being so late, but only now I had some time to read through the
> libGDB architecture proposal thread.

My turn for being slow :-(

> Andrew, please correct me if I'm wrong here. My understanding of the proposal
> is that we'll have an abstract layer on top of GDB that receives commands
> through an input stream and spits out the GDB internal structures in a given
> format, that could easily be changed to meet one's particular needs. There are
> at least two obvious advantages for such an approach: (1) there is no need to
> change much of the GDB's internals in order to support it and (2) a libGDB
> client could be implemented in any language, since there's no coupling between
> the two layers.

No, yes, kind of.

The proposal is to identify a set of GDB operations and publish them
using a, C based, function-call interface. An interpreter would be
expected to implement bindings to that interface.

Initially, it is expected that some of those C-functions will be mapped
directly onto existing interpreter commands  (gdb_lib_breakpoint_delete
(int n) -> ``"delete %d", bp'').  Then, as GDB's internals are modified
more direct implementations will be possible.

As part of the interface, the idea is to re-define the way GDB creates
its output.  Where previously breakpoint.c:breakpoint_1() used a
sequence of printf's to output a line of breakpoint information:

      printf_filtered ("%-3d ", b->number);
      printf_filtered ("%-14s ", bptypes[(int) b->type].description);
      printf_filtered ("%-4s ", bpdisps[(int) b->disposition]);
      printf_filtered ("%-3c ", bpenables[(int) b->enable]);

it would instead use a sequence like:

      ui_out_field_int (uiout, "number", b->number);
      ui_out_field_string (uiout, "type", bptypes[(int)
b->type].description);
      ui_out_field_string (uiout, "disp", bpdisps[(int)
b->disposition]);
      ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)
b->enable]);

to construct the breakpoint result (the next step in the discussion is
hopefully that interface).

As part of the eixsting CLI there would be ui_out* functions that sent
all output straight through to the console (well GDB_STDOUT). Other
clients would implement their own ui_out and construct a breakpoint
description in their own special way

Importantly, the same code would be used when producing output for the
CLI and for some other client.  This means that, at all stages, the code
being changed would continue to be exercised by the existing testsuite.

The alternative would be to provide a new and separate interface into
GDB's internals. Looking at what has happened so far, people (ddd
especially) has been remarkably content with just GDB's CLI.  (Ignoring
the perenial of the output just changed).

I do expect people to gradually implement new modules, not accessible
from the CLI, that really do grub around in GDB's internals.  By
sticking to the interface being developed here, that could would
hopefully be available for all.


> Here are some of my observations of what's going on so far.
> 
> From the the work that Jim Ingham, Tom Tromey, Keith Seitz, Martin Hunt and
> others did inside Cygnus on the gdbtk interface, from my previous experience
> with a Perl prototype and the current Python integration work we're doing here
> and from the work that Martin Baulig is doing on the Guile interface, it looks
> like we need a more tightly coupled interface with GDB. It seems that what we
> really need is the ability to have access to the internal GDB structures and
> functions directly and not through an additional layer, which adds a certain
> amount of burden in how you deal with GDB internals.

How close is close?  I'm aiming at an interface that is efficient and
reliable (hence C-function call) without exposing the nitty gritty
internal GDB details.  Hopefully that gives the interpreter the
performance it needs without commiting GDB to supporting specific
internal details at infinitum :-)

> It also looks like there is a lot of code duplication in all these glue layers.
> Things like getting the backtrace, finding the function name given a pc and
> lots more are copied from various places in GDB in all these clients. This is
> not a good thing since it doesn't promote code reuse. In addition, fixing a bug
> somewhere requires fixes in the other places that copied the code.

Yes. Rationalizing the code is a wishlist item.

Going back to the breakpoint example.  GDB currently contains several
independant blocks of code that it uses to display breakpoint
information: info-breakpoint; set-breakpoint; target-stopped/WFI and
even ``file'' display breakpoint information. There should only be one
mechanism and anything else wanting to display breakpoint information
should use that.

A client of libGDB would only have access to the direct call ``info
breakpoint''.  A person reviewing the breakpoint code would only
consider modifying ``info breakpoint''.  Any other operations (such as
set-breakpoint) would not return any information (other than possibly an
event advising that breakpoint state was changed).

> This happens because GDB's code does not make a clear distinction between the
> parts that do actual computation and the ones that print out the results. I
> think we should try to separate the two parts and have computation functions
> and associated printing functions. Computation functions should just create
> structures or set-up global values that are used later on by the printing
> functions. These would just walk on existing structures and print out their
> content.

Yes.  I suspect you're actually describing what we're trying to do :-) 
Sounds like I botched my description.

> With this approach it's a lot easier to glue on top of GDB clients like gdbtk,
> Guile, Python or whatever else, because all we have to do then is just export
> the functions that we need using SWIG and they automagically appear as native
> functions in the interpreted languages that SWIG supports (Tcl, Guile, Python,
> Perl and even Java).

(SWIG, just love that acronym :-)

> The next thing after this is to figure out a way to have all these languages
> share code and data between them. Imagine that there is a piece of code which
> you need in Guile, but you don't want to rewrite it in Python in order to be
> able to use it. Having the ability to call Guile code from Python and passing
> back and forth data in and from your favorite language would be very nice. The
> idea is to have people scripting GDB in Perl, Guile, Tcl or Python, all at
> once, from the same binary. This would be the true freedom of the user ;-)! But
> this is a completely different story...

:-)

> Does the approach of separating the functionality inside GDB sound reasonable?
> I know that there's a lot more work than what Andrew proposed but I think this
> will help us a lot in the long run.

As a holy grail we have a separate CLI that uses the same interface as
all the other components :-)

As I hinted above, when formumulating an overall plan we considered
creating an entirely new interface (rather than evolving the old one). 
It was felt that by putting the emphasis on evolving the existing code
it would be possible to both leverage (as a verb? :-) the existing
testsuite and consolidate the existing code base.  Creating a new
separate independant interface would have ment the duplication
significant amounts of GDB.

	enjoy,
		Andrew
From ovidiu@cup.hp.com Mon Sep 06 22:54:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Ovidiu Predescu <ovidiu@cup.hp.com>, gdb@sourceware.cygnus.com
Subject: Re: libGDB architecture 
Date: Mon, 06 Sep 1999 22:54:00 -0000
Message-id: <199909070551.WAA30205@hercules.cup.hp.com>
References: <37D36E8A.3B05D73B@cygnus.com>
X-SW-Source: 1999-q3/msg00296.html
Content-length: 2530

Hi Andrew,

On Mon, 06 Sep 1999 17:34:34 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:

> > Sorry for being so late, but only now I had some time to read through the
> > libGDB architecture proposal thread.
> 
> My turn for being slow :-(

;-)

> The proposal is to identify a set of GDB operations and publish them
> using a, C based, function-call interface. An interpreter would be
> expected to implement bindings to that interface.
> 
> Initially, it is expected that some of those C-functions will be mapped
> directly onto existing interpreter commands  (gdb_lib_breakpoint_delete
> (int n) -> ``"delete %d", bp'').  Then, as GDB's internals are modified
> more direct implementations will be possible.

Aha, I think I understand where you're coming from!

Where does libGDB live in your proposal? Does it live in the client process,
aka outside GDB's process? If yes, then we are talking about two different
things. Your proposal defines a way for the client to make calls into GDB and
to be informed whenever some event occurs. You present to the client a set of C
functions that under the hood talk to GDB via a dedicated protocol. The user (a
programmer of course) can also modify the way the output comes from GDB by
changing the ui_out* functions you're talking about, but to be able to do this
he has to add these new functions and rebuild GDB.

My proposal is essentially the same set of C functions as yours but this time
they live in the GDB process. The API includes functions to access the GDB's
functionality and, in addition, it exports some of the internal GDB's
structures either as opaque pointers or as structures that contain general
enough members that don't modify over time. (So the answer to your question
"how close is close?" is "very close" ;-)

It is the above C API that is exposed to various interpreted languages using
SWIG. However both the glue code and the interpreter live in the same process
space with GDB.

In my proposal libGDB exposes only the GDB internals and it is not concerned at
all with how this data is passed between GDB and an external process. However,
once you have an interpreter built in GDB you could expose the internals using
various mechanisms: with CLI/ annotations as today, using Corba, RPC, XML-RPC,
HTTP/HTML or whatever else the user wants to use.

Could you please clarify the above point? If my understanding is not right,
then I have to read again all the messages on this thread to get a better
understanding of your proposal ;-).

Greetings,
Ovidiu