* Re: Proposal: --with-gdb-interpreter=... --interpreter=...
1999-08-18 17:39 Proposal: --with-gdb-interpreter=... --interpreter= Andrew Cagney
@ 1999-08-18 17:53 ` Stan Shebs
1999-08-19 19:30 ` Jim Blandy
1 sibling, 0 replies; 3+ messages in thread
From: Stan Shebs @ 1999-08-18 17:53 UTC (permalink / raw)
To: cagney; +Cc: gdb, insight
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Proposal: --with-gdb-interpreter=... --interpreter=...
1999-08-18 17:39 Proposal: --with-gdb-interpreter=... --interpreter= Andrew Cagney
1999-08-18 17:53 ` Stan Shebs
@ 1999-08-19 19:30 ` Jim Blandy
1 sibling, 0 replies; 3+ messages in thread
From: Jim Blandy @ 1999-08-19 19:30 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb, insight
Recommended autoconf practice is to name your flags --with-FEATURE.
Thus, --with-guile, --with-python, etc.
From msnyder@cygnus.com Thu Aug 19 22:45:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Thu, 19 Aug 1999 22:45:00 -0000
Message-id: <37BCE83E.6AEF@cygnus.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> <199908151234.IAA14013@mescaline.gnu.org>
X-SW-Source: 1999-q3/msg00209.html
Content-length: 555
Eli Zaretskii wrote:
>
> From: jtc@redback.com (J.T. Conklin)
> Date: 13 Aug 1999 16:49:25 -0700
>
> > I believe the enclosed code from can_use_hardware_watchpoint() has a
> > problem, but I'm unsure of the proper fix.
>
> As long as we are talking about this function, here's another
> question: shouldn't the loop below return zero as soon as the first
> value is found on the value chain that is NOT okay to watch (as the
> macro TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT says)?
Yes. I've checked in your suggested change for that.
From msnyder@cygnus.com Thu Aug 19 22:45:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Thu, 19 Aug 1999 22:45:00 -0000
Message-id: <37BCE7F2.7BB8@cygnus.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00210.html
Content-length: 802
J.T. Conklin wrote:
>
> The problem is that a expression containing a register variable will
> not cause this function to fail (return 0). This seems to result in
> GDB forging ahead and placing a hardware watchpoint at a random
> address for the register variable. An example of this is something
> like 'watch mem[reg] != 0'.
> [...]
> One solution is to add an:
>
> else if (v->lval == lval_register)
> return 0;
I'm leaning toward agreeing with this...
>
> But I'm wondering if instead the v->modifiable == 0 should be == 1
> instead.
Could you elaborate on that thought?
I'm not sure I understand why the function should give a negative
return if a subexpression is not_lval and !modifiable. Is it
trying to detect constants? Or what?
Michael
From ovidiu@cup.hp.com Thu Aug 19 23:07:00 1999
From: ovidiu@cup.hp.com
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com
Subject: Re: Proposal: --with-gdb-interpreter=... --interpreter=...
Date: Thu, 19 Aug 1999 23:07:00 -0000
Message-id: <199908200605.XAA02169@hercules.cup.hp.com>
References: <37BB5209.BD61A49@cygnus.com>
X-SW-Source: 1999-q3/msg00211.html
Content-length: 1499
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/
^ permalink raw reply [flat|nested] 3+ messages in thread