From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Andrew Cagney Cc: gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com Subject: Re: Proposal: --with-gdb-interpreter=... --interpreter=... Date: Thu, 19 Aug 1999 19:30:00 -0000 Message-id: References: <37BB5209.BD61A49@cygnus.com> X-SW-Source: 1999-q3/msg00208.html 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 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 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 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 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 http://andromeda.cup.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/