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

[Stan Shebs <shebs@cygnus.com>]

   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
From ac131313@cygnus.com Wed Aug 18 18:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: ian@zembu.com, binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Default architecture according --target=...configury?
Date: Wed, 18 Aug 1999 18:15:00 -0000
Message-id: <37BB5A35.50A1F9C2@cygnus.com>
References: <199908190027.RAA25601@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00202.html
Content-length: 1677

Stan Shebs wrote:
> 
>    Date: Thu, 19 Aug 1999 10:12:31 +1000
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    >    PS: Why?  I'd like GDB to make a better guess at a default
>    >    architecture.  bfd_default_arch_struct just isn't very interesting.
>    >
>    > If you explain further what you mean by this, perhaps we can think of
>    > some way to make it work for you.  When does gdb want to know the
>    > default architecture?  What is it going to do with the information?
> 
>    Consider a GDB which has been built to support several different ISA's
>    (a mips4111, mips4300, ...).  What architecture should GDB select by
>    default when it goes to talk to a remote target?
> 
> I don't think it should be BFD's place to choose GDB's default target
> architecture.  BFD is just an object file reader.  GDB should assume
> an architecture compatible with the executable it is handed, and it
> should try to get it from the remote target if possible.  If neither
> is helpful or available, the default should be defined in GDB's
> configury somewhere.

When GDB is handed an executable it analyzes it (using BFD) and sets its
architecture accordingly.  For a remote target it should auto-detect the
architecture and again, for a few cases, it does that two.

The problem arises when there is no additional information available. 
As you suggest, one possibly is for GDB to configure a default arch
internally.  It just seems strange to me that GAS, BFD and GDB are all
doing it their own special way.

As an aside, GAS (well opcodes) uses BFD's config.bfd to determine
architecture information.  GDB has its own special configure.tgt.

	enjoy,
		Andrew
From brendan@dgs.monash.edu.au Wed Aug 18 18:30:00 1999
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: egcs@cygnus.com
Cc: gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com
Subject: Re: GDB and Insight CVS repositories.
Date: Wed, 18 Aug 1999 18:30:00 -0000
Message-id: <37BB5E59.C4BB46BC@dgs.monash.edu.au>
References: <199908190042.RAA27565@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00203.html
Content-length: 2264

Stan Shebs wrote:

>    If so, it makes sense to me that there
>    is only one master source repository for Insight and GDB.  Those that
>    don't want a GUI can build with something like "make all-gdb
>    install-gdb" and those who want the GUI can build with something like
>    "make all install" or "make all-insight install-insight".  It seems
>    logical to me and can't see why 2 repositories should exist.  Maybe this
>    is just an interim thing until Insight is officially released.
>
> Makes sense to me too...  In fact, in a GDB with Insight configured in,
> the GUI comes up by default if an X display is available, unless you
> say "-nw" (we imitated Emacs behavior).
>
>    I guess the other option is to seperate the GUI sources from GDB
>    sources.  I'm not sure of the details of how this would be done but
>    believe it is possible.  Are there any technical reasons why this can't
>    or shouldn't be done.
>
> It could be done.  The main downside to trying to make it a separate
> package is that Insight is linked closely to GDB - it would be
> difficult (though not impossible) to make current Insight sources work
> with vanilla 4.18, for instance.  The "easy" separation would be to
> make it a separate source package that you can unpack on top of a GDB
> source tree - would take a few days to figure that one out.  The
> "hard" separation would be to make Insight a separate program; that
> would be several months of fulltime work.

From a purist point of view I think it would be better to keep the packages
seperate, regardless of whether Insight is built as a seperate application or
an integrated application.  If it is relatively simple to unpack Insight
sources into a seperate sub directory of the GDB source then this sounds like
it would keep RMS happy and keep the GUI repository seperate from the GDB
repository.  I guess this is akin to gcc-core, gcc-c++, gcc-fortran, etc
distribution archives.  I guess the difference is that all these components
are officialy accepted by GNU.

If this was to happen, would this mean that gdb would require patches ?

Does GDB have an external API (interprocess comms, TCP/UDP sockets) so that
other GUIs could communicate without having to parse CLI output ?

Brendan Simon.