Hi,

The attached patch improves the robustness of Z0 packet detection. In some
rare cases on some targets, the remote_insert_breakpoint behaves
differently for the first breakpoint attempted, as a result of the Z0
packet support detection. The problem is that GDB modifies the address
information used as part of the detection, by passing in the address to use
to gdbarch_breakpoint_from_pc, which on some target vectors (in my case
MIPS16, although it's also conceivable for Thumb to be affected) modifies
the address.

If the Z0 packet is unknown, it drops through to memory_insert_breakpoint
passing it the modified address. This can cause a change in later
heuristics within the target support when the target tries to detect the
form of breakpoint required (e.g. 2 versus 4 byte).

You can see this in the implementation of e.g. mips_breakpoint_from_pc,
which will look at the PC first, to determine the breakpoint style to use,
not the length. Most of the times this works, but in some particular cases,
depending on particular characteristics of the symbol, it can fail to
detect mips16 addresses. Whereas it could detect them if the address had
been unmodified.

I have check-in permissions, so can commit after approval if that helps.

Jifl

2008-06-27  Jonathan Larmour  <jifl@eCosCentric.com>

	* remote.c (remote_insert_breakpoint): Ensure that if Z0
	unsupported and we fall back to memory_insert_breakpoint, we
	use the unmodified requested address.


-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine