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

[Jim Blandy <jimb@cygnus.com>]

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/