gdbstub: Define behaviour on adding multiple breakpoints with same address and type (but different sizes)

[DimitriPilot3]

Possibly a placebo issue, but could be interesting. And I have absolutely no experience in that matter :P

rwatch *(float *)0x5DA854
rwatch *(short *)0x5DA854
rwatch *(long long *)0x5DA854

To the GDB client, these are three distinct and valid watchpoints, which... when committed to the stub's runtime... become just one! They all compete for the same address key in a single std::map. Only the first breakpoint entry is retained at runtime (as per std::map::insert's behaviour).

And in theory (you can slap me if that doesn't happen in practice), if GDB decides to only remove some but not all breakpoints, then there will still be no run-time watchpoints left. Lol.

[DimitriPilot3]

Turns out gdbserver indexes its breakpoints on removal in the same way they were added, using the same three parameters that are provided by the Ztype,addr,kind or ztype,addr,kind command syntax.
In other words, gdbserver finds and removes at most one breakpoint whose type, address, AND kind, all meet the request! (Unless gdb requested kind = -1, then only the type and address are compared.)

For a Z2..Z4 watchpoint, the kind is defined as a number of bytes; for Z0 and Z1 breakpoints, it is an architecture-specific value if one exists, otherwise, it is 0.

• I wish to unite the kind field into our stub's breakpoint key somehow.
• Or the stub could keep track of multiple breakpoint entries per kind for the same (type, address) pair.