Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 03 May 2011 07:05:35, Eli Zaretskii wrote:
> We should resolve this conflict in the most direct way: introduce a
> method, to be implemented by each target, that will answer these
> questions.  It should accept the exact spec of the new watchpoint, and
> it should have access to the watchpoints and breakpoints already set,
> including their full specs.  With that information in hand, a target
> can reliably produce a definitive response, at least in the vast
> majority of cases, when the corresponding resources are under GDB
> control.

Consider:

 gdb core -> target_ops -> remote -> remote stub -> debug API (something that actually inserts/remove watchpoints, and hides resource accounting details)

Currently, the accounting is done between gdb core and the target_ops
implementation, using target methods.

Many debug support libraries (that abstract access to jtag,
for example), and debug APIs (like ptrace) don't expose programatic methods
to do resource accounting to be able to implement such new method either.
They may even do watchpoint merging themselves (e.g., overlapping watchpoints
consume only one registers, instead of two), making it impossibly to
implement the new method other than always returning "it fits".
With such targets, the only reliable way to know whether the watchpoint
resources haven't been exausted, is to actually try to insert the watchpoint.
But this should work for the simplest APIs, like those where the backend
manages a finite set of debug registers (like most i386 backends).

What if we tried to make GDB do that instead? (try inserting
watchpoint immediately, instead of trying to do any sort of
accounting.)

-- 
Pedro Alves