Limiting breakpoints sensibly

Limiting breakpoints sensibly

[Nathan J. Williams]

I'm working on a remote stub and GDB architecture implementation for a
small embedded system, based on 6.3. Among the quirks of this system
are that the code is in flash, which is not writable from the stub's
perspective. This means that all breakpoint requests have to go
through the single breakpoint register. This works fine with one
breakpoint. However, when the user tries to insert more than one
breakpoint, things go poorly.

I wrote the stub to return an error when a breakpoint is already set;
this seemed more sensible than letting all of the requests proceed and
just taking the first or the last one. When remote_insert_breakpoint()
gets the error on the second breakpoint and bails out (with an
unfortunate error message of "Unknown error: 4294967295"), nothing
unwinds the state of the first breakpoint, and it remains set on the
target. If the user then disables the first breakpoint and sets the
second, the stub will complain about setting the second stub. If the
user disables all breakpoints and continues, the first one is still
there to fire.

What I'd like is a way to limit breakpoints with some useful
feedback. The remote_hw_breakpoint_limit variable seems like the right
thing, but it looks like it's for the user to set, and I want my
target architecture to set it somehow. Is it okay to just mash the
variable in my target init routine - nothing else seems to do that -
or is there a better approach to setting this limit?

        - Nathan