Proposal: --with-gdb-interpreter=... --interpreter=...

Proposal: --with-gdb-interpreter=... --interpreter=...

[Andrew Cagney]

Hello,

We're now starting to see the situtation where GDB can support multiple
interpreters.  At present there is GDB's traditional CLI, the TUI (from
HP) and TCL/TK.  We've had many threads of Python, Perl, Java, Visual
Basic and evey guile interpreters comming in down the track.

What I'd like to do is set in motion  change that should greatly
simplify the integration of various interpreters.  Accordingly I'd like
to propose the following changes:


	o	configure ... --with-gdb-interpreter=<interpreter-list> ...

		This allows the user to specify the interpreter
		(in addition to the default CLI) that is built
		and linked into GDB.

		The configury assumes that there is a directory

			.../gdb/<interperter>

		that contains all the useful bits (Makefile stub,
		sourcecode, ...).


	o	a new option ``--interpreter=...'' that can be used
		to specify the interpreter to use during startup.

Andrew

PS: I need to check that --with is the correct option.

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[Stan Shebs]

   Date: Thu, 19 Aug 1999 10:38:33 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   We're now starting to see the situtation where GDB can support multiple
   interpreters.  At present there is GDB's traditional CLI, the TUI (from
   HP) and TCL/TK.  We've had many threads of Python, Perl, Java, Visual
   Basic and evey guile interpreters comming in down the track.

   What I'd like to do is set in motion  change that should greatly
   simplify the integration of various interpreters.  Accordingly I'd like
   to propose the following changes:

Of course I think this is a great idea!  It occurs to me that the
situation is very similar to that in GCC, where the language-specific
frontends live in subdirs.  It's not identical, because each frontend
results in a distinct executable (cc1plus, etc), while for GDB we'd
rather end up with a single debugger, but the configury and makefile
fragment ideas could be useful to learn from.

								Stan

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[Andrew Cagney]

[Ben, as the autoconf maintainer you might have an idea]

Stan Shebs wrote:
> 
>    Date: Thu, 19 Aug 1999 10:38:33 +1000
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    We're now starting to see the situtation where GDB can support multiple
>    interpreters.  At present there is GDB's traditional CLI, the TUI (from
>    HP) and TCL/TK.  We've had many threads of Python, Perl, Java, Visual
>    Basic and evey guile interpreters comming in down the track.
> 
>    What I'd like to do is set in motion  change that should greatly
>    simplify the integration of various interpreters.  Accordingly I'd like
>    to propose the following changes:
> 
> Of course I think this is a great idea!  It occurs to me that the
> situation is very similar to that in GCC, where the language-specific
> frontends live in subdirs.  It's not identical, because each frontend
> results in a distinct executable (cc1plus, etc), while for GDB we'd
> rather end up with a single debugger, but the configury and makefile
> fragment ideas could be useful to learn from.

Progress?

It works provided the interpreter being added doesn't depend on any
complex configure actions.  The TUI fits in well with this model - no
TUI stuff in gdb/Makefile.in has to be a good thing :-)


Insight on the other hand is looking more difficult.  It needs to link
in a random set of extra libraries (X11, tk, tcl, ...) and relies on
configure to find them.  I can see two possible ways of handling this:

	o	gdb/configure.in include checks those libraries

	o	gdb/insight/configure.in treated as a separate
		independant sub-directory and be configured/built
		accordingly.

comments, suggestions?

	Andrew

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[Jim Blandy]

Recommended autoconf practice is to name your flags --with-FEATURE.
Thus, --with-guile, --with-python, etc.

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[Andrew Cagney]

Jim Blandy wrote:
> 
> Recommended autoconf practice is to name your flags --with-FEATURE.
> Thus, --with-guile, --with-python, etc.

I don't know.  Is python embedded in GDB the addition of a new feature
or the use of an additional package?  It's probably both ....

	Andrew

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[ovidiu]

On Thu, 19 Aug 1999 10:38:33 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:

> [...]
>
> 	o	a new option ``--interpreter=...'' that can be used
> 		to specify the interpreter to use during startup.

I propose the flag to be simply called -perl, -python, -tcl, -guile etc. In
addition to this the flag should take an additional argument which should
represent the name of a script in that language. This would allow the user to
write full scripts to work with gdb.

I have an old, rudimentary prototype built in Perl that works like this and is
quite nice to have the ability to run gdb from a driver script. I basically
replaced the normal GDB command loop with one that's written in Perl. I
exported the execute_command() function and all the names of the GDB commands
to Perl so that I could call GDB commands from Perl. The Perl driver loop had
two modes: a normal GDB mode in which lines entered by the user are treated as
normal GDB commands. The other mode is a Perl mode, all the input lines are
accumulated until a special key is hit (Ctrl-x), at which point the input is
executed as Perl code. The Perl driver loop even extended the normal GDB
command line syntax by adding capabilities for passing the output of a command
through an arbitrary Unix pipe or passing the input of such a pipe as arguments
of a GDB command.


Greetings,
--
Ovidiu Predescu <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[ovidiu]

On Thu, 19 Aug 1999 23:05:13 -0700, ovidiu@cup.hp.com wrote:

> On Thu, 19 Aug 1999 10:38:33 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:
> 
> > [...]
> >
> > 	o	a new option ``--interpreter=...'' that can be used
> > 		to specify the interpreter to use during startup.
> 
> I propose the flag to be simply called -perl, -python, -tcl, -guile etc. In
> addition to this the flag should take an additional argument which should
> represent the name of a script in that language. This would allow the user to
> write full scripts to work with gdb.

I forgot to say it, but this allows one to write things like:

#! /bin/gdb -perl

# insert your favorite Perl code here to manipulate gdb's internals


Greetings,
--
Ovidiu Predescu <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/

Re: Proposal: --with-gdb-interpreter=... --interpreter=...

[Andrew Cagney]

ovidiu@cup.hp.com wrote:
> 
> On Thu, 19 Aug 1999 23:05:13 -0700, ovidiu@cup.hp.com wrote:
> 
> > On Thu, 19 Aug 1999 10:38:33 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:
> >
> > > [...]
> > >
> > >     o       a new option ``--interpreter=...'' that can be used
> > >             to specify the interpreter to use during startup.

		Short form ``-i perl''

> > I propose the flag to be simply called -perl, -python, -tcl, -guile etc. In
> > addition to this the flag should take an additional argument which should
> > represent the name of a script in that language. This would allow the user to
> > write full scripts to work with gdb.
> 
> I forgot to say it, but this allows one to write things like:
> 
> #! /bin/gdb -perl

FYI, that should at least be ``--perl'' and:

	#!/bin/gdb --interpreter=perl

would work as well :-)

As to the more important policy question.  How should that option be
specified.  My personal preference is to sub-option it (hence
--interpreter/-i) that way there is uniformity.  The HumanFactors/Style
decision is up to the chief architect.

There is also a second question lurking here.  Should an interpreter be
allowed to add extra options to the command line?  My preference here is
no.  Again, however, it's a question of style.

	enjoy,
		Andrew