From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: cagney@cygnus.com Cc: gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com Subject: Re: Proposal: --with-gdb-interpreter=... --interpreter=... Date: Wed, 18 Aug 1999 17:53:00 -0000 Message-id: <199908190052.RAA27597@andros.cygnus.com> References: <37BB5209.BD61A49@cygnus.com> X-SW-Source: 1999-q3/msg00201.html Date: Thu, 19 Aug 1999 10:38:33 +1000 From: Andrew Cagney 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 To: Stan Shebs 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 > > > 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 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.