Re: Runtiming hw watchpoints; Was: Split up Z packet enable/disable cmd

[Fernando Nasser <fnasser@cygnus.com>]

Thanks, that is a very good summary.

Let me comment...


Eli Zaretskii wrote:
> 
> > Date: Thu, 03 Aug 2000 13:21:47 +1000
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > I.E. delay assigning watchpoints to hardware/software until the last
> > moment.  Instead of having watch_command_1()  try to select a hw/sw
> > watchpoint before it knows the answer, the code inserting the watchpoint
> > could do it and just set ->hw if it succeeded.
> 
> Yes, I think this is the only reasonable way, eventually.
> 

Delaying the decision for watchpoints is hard because the software implementation
is something not atomic, much different from the sw breakpoint which is basically
alter a memory position.  The software implementation of watchpoints includes
an arbitrary number of single-steps and processing on inferior event.

Note that once the user realizes his/her target do have hardware support for 
watchpoints he/she can either:
1) Use target first, before inserting watchpoints
2) Add "set harware-watchpoints enable" to her/his .gdbinit file

Nothing that the manual or a good error message text can't fix.


> The problem is that the code which is run when the user says "watch
> foo" doesn't know how many other watchpoints, and of what kind, will
> be needed when the inferior is resumed.  In particular, all kinds of
> breakpoints with commands that set, reset, or enable watchpoints may
> be lying around; a target may be able to combine several watchpoints
> into one, but only under some conditions; etc.  You don't know all
> that stuff until it's time to resume, and only the target code knows
> the entire truth.
> 

The code in breakpoints does collect the necessary information and pass it
as arguments to the macro.  We just have to write the appropriate code for
each architecture.  The check is part architecture dependent and part target
dependent.  My implementation allow for both checks.

The macro (is it already at gdbarch?  If not it should) invokes the architecture
dependent code (in i386-tdep.c in my case) and that uses the target vector above
to check the target dependent parts.

I believe we always should go through these two layers, in that order, for things
that are both arch and target dependent.


> Automatic fallback to software watchpoints might be useful, but IMHO
> it must be a user option, because in many cases, if I know that my
> resources for hardware watchpoints are not enough to cover all of the
> watches, I might wish to reconsider instead of letting the program to
> crawl...
> 

set hardware-watchpoints disable   (the default will be auto)

> However, with the current machinery, it is very hard to delay the
> hw/sw decision to the point where the inferior is resumed.  This is
> because high-level code in GDB needs to know whether there are any
> software watchpoints, to arrange for single-stepping.  Since the
> decision can only be reliably made by the target-specific code, by the
> time it knows that, it's too late.  We need some way of communicating
> that information back to GDB's application code, before resume() and
> its brethren is called.

Exactly.  Unless we want the watchpoint support to remain in the TODO list
for a very long time we must set for a initial solution that does not require
a huge amount of code rewriting.  In this case I would bet it would need a
major architectural change.




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From guo@cup.hp.com Thu Aug 03 10:03:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] language support: case sensitivity 
Date: Thu, 03 Aug 2000 10:03:00 -0000
Message-id: <Pine.LNX.4.10.10008030953070.17962-100000@hpcll168.cup.hp.com>
References: <200008031433.KAA04437@texas.cygnus.com>
X-SW-Source: 2000-08/msg00064.html
Content-length: 3031

Actually the two commands added are:
	 set case-sensitive (on/off/auto)
	 show case-sensitive

It's not correct that nothing would be print if case sensitivity is set
same as the language default and if the user issues the show command.
As I said, do_setshow_command () in command.c handles that part.
Looking at the 'set/show language' implementation, there's nothing
different between the two -- one would expect that if this patch needs a
different command to support user query, then show_language would too.

Just to show this, here's what I got from GDB on a C application:

(gdb) show case-sensitive
Case sensitivity in name search is "auto; currently on".
(gdb) set case-sensitive on
(gdb) show case-sensitive
Case sensitivity in name search is "on".
(gdb) show language
The current source language is "auto; currently c".
(gdb) set language c
(gdb) show language
The current source language is "c".

- Jimmy

On Thu, 3 Aug 2000, David Taylor wrote:

>    Date: Wed, 2 Aug 2000 09:55:23 -0700 (PDT)
>    From: Jimmy Guo <guo@cup.hp.com>
>
>    I don't quite understand yet the need for having a new show command
>    routine ... command.c (do_setshow_command) seems to be the one that
>    handle the normal output of settings.  Also, show_language_command
>    has similar setup as show_case_command ().  Do you have an example on
>    the kind of behavior you'd like to see but not supported currently by
>    this patch?
>
>    - Jimmy Guo, guo@cup.hp.com
>
>You added two commands:
>
>  set case-sensitivity
>  show case-sensitivity
>
>And if the user types "show case-sensitivity", nothing will print
>unless the sensitivity differs from that of the current language.  I
>feel that if the user *ASKED* to be shown the case sensitivity, then
>the user should be *SHOWN* the case sensitivity.  If the user
>explicitily asks what it is, then it should not be silent.
>
>So, you could have the command "show case-sensitivity" print something like:
>
>  Case sensitivity is on.
>  warning: current language, fortran, is case insensitive.
>
>Where the first line is printed by a new function (to be called when
>the user types "show case-sensitivity"), and the second line is
>printed by the function (renamed) that currently implements "show
>case-sensitivity".
>
>[...]
>    >Your new function show_case_command plays double duty -- it is both
>    >invoked by other functions / commands and it is invoked by the user in
>    >response to the 'show case' command.  And while it is quite reasonable
>    >for it to be silent when it is *NOT* invoked by the user, it should
>    >not be silent when it is invoked by the user.
>    >
>    >My suggestion is to define two functions:
>    >
>    >. one, the new show_case_command, which is never silent -- it always
>    >tells you the setting.
>    >
>    >. the other, the current show_case_command, prints a warning if
>    >appropriate and is called by the current callers of show_case_command.
>    >
>    >Otherwise it looks fine to me.  Thanks for submitting this.
>
>