This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: awatch and rwatch vs watch


>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
Eli> I expect this to be implemented in a similar way for other x86
Eli> platforms, but maybe this is not so.  Can someone confirm or refute
Eli> this?

This is more or less the way I implemented hardware watchpoints on our
x86 embedded targets.

Eli> Here, can_use_hardware_watchpoint simply makes sure that the
Eli> expression to be watched doesn't yield a data type whose length is
Eli> more than the target hardware watchpoint facility can handle.  For
Eli> example, if the target cannot watch more that 4-byte regions, then
Eli> "watch foo" where `foo' is a double will cause GDB use a software
Eli> watchpoint for `foo'.

Eli> It seems that this snippet implies that software watchpoints cannot be
Eli> set with "awatch" and "rwatch", only with "watch".

Correct.

Eli> Can someone tell why?  Should I submit a patch to handle all
Eli> watchpoints equally, at least on x86 platforms?

Access watchpoints are triggered when a memory location is read or
written and read watchpoints are triggered when a memory location is
read.  Although it would be possible to examine instructions as they
are exectured to see if they the accessed memory locations specified
in a software watchpoint, that is currently not done.  Instead, soft-
ware watchpoints simply evaluate an expression after each step and
check if the value changes.  Given the current implementation, it is 
impossible to set a read or access watchpoint without hardware assist.

Eli> Btw, the manual clearly has traces of limitations that are pertinent
Eli> for platforms other than x86: it says something about "setting both
Eli> watchpoints with the same command" (what ``both watchpoints''?).

Correct.  I think the manual refers to the sparclite.  A patch to fix it
would not be inapropriate.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]