Handle the case of a remote target supporting target side commands, but not on software breakpoints.

Although we can tell upfront whether a remote target supports target
side commands, we can only tell whether the target supports that in
combination with a given breakpoint kind (software, hardware,
watchpoints, etc.) when we go and try to insert such a breakpoint kind
the first time.  It's not desirable to make remote_insert_breakpoint
simply return -1 in this case, because if the breakpoint was set in a
shared library, insert_bp_location will assume that the breakpoint
insertion failed because the library wasn't mapped in.

insert_bp_location already handles errors/exceptions thrown from the
target_insert_xxx methods, exactly so the backend can tell the user
the detailed reason the insertion of hw breakpoints failed.  But, in
the case of software breakpoints, it discards the detailed error
message.

So the patch makes insert_bp_location use the error's message for SW
breakpoints too, and, introduces a NOT_SUPPORTED_ERROR error code so
that insert_bp_location doesn't confuse the error for failure due to a
shared library disappearing.

The result is:

(gdb) c
Warning:
Cannot insert breakpoint 2: Target doesn't support breakpoints that have target side commands.

2014-01-09  Pedro Alves  <palves@redhat.com>
	    Hui Zhu  <hui@codesourcery.com>

	PR gdb/16101
	* breakpoint.c (insert_bp_location): Rename hw_bp_err_string to
	bp_err_string.  Don't mark the location shlib_disabled if the
	error thrown wasn't a generic or memory error.  Catch errors
	thrown while inserting breakpoints in overlayed code.  Output
	error message of software breakpoints.
	* remote.c (remote_insert_breakpoint): If this breakpoint has
	target-side commands but this stub doesn't support Z0 packets,
	throw NOT_SUPPORTED_ERROR error.
	* exceptions.h (enum errors) <NOT_SUPPORTED_ERROR>: New error.
	* target.h (target_insert_breakpoint): Extend comment.
	(target_insert_hw_breakpoint): Add comment.

0 files changed, 0 insertions, 0 deletions