This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

Re: TARGET_REGION_OK_FOR_HW_WATCHPOINT in target vector


> Date: Fri, 20 Sep 2002 17:56:40 -0400
> From: Andrew Cagney <ac131313@ges.redhat.com>
> 
> I know of an architecture (need to find out if it is public) where some 
> addr:len pairs require more than a single watch resource.  Without it, 
> the target would assume that every watchpoint is a worst case (needing 
> max resources) and count accordingly.

I think this already happens for the targets that use
TARGET_REGION_OK_FOR_HW_WATCHPOINT as it's defined now.  The result is
that the application level in GDB's code doesn't have a clear idea how
many watchpoint resources are required for a given watchpoint, and
thus GDB can try to set the watchpoint and get a failure indication
from the target end.  Target ends need to deal with this problem in a
way similar to what i386-nat.c does.

IIRC, there's no easy way of fixing this problem in general, since
that would require either (1) that the application level knows too
much about the target limitations, or (2) that the target end knows
too much about the semantics of the breakpoint structure members.

So I think it might not be wise to try to do what you suggest, because
the general problem will remain unsolved, and target ends will still
need to be prepared for this kind of calimities.  Targets where the
decision whether a region is okay for watching is very complicated
might wish to define TARGET_REGION_OK_FOR_HW_WATCHPOINT as 1, and do
the necessary decision when GDB actually tries to insert the
watchpoint.


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