Support single step by arch or target

Nowadays, GDB only knows whether architecture supports hardware single
step or software single step (through gdbarch hook software_single_step),
and for a given instruction or instruction sequence, GDB knows how to
do single step (hardware or software).  However, GDB doesn't know whether
the target supports hardware single step.  It is possible that the
architecture doesn't support hardware single step, such as arm, but
the target supports, such as simulator.  This was discussed in this
thread https://www.sourceware.org/ml/gdb/2009-12/msg00033.html before.

I encounter this problem for aarch64 multi-arch support.  When aarch64
debugs arm program, gdbarch is arm, so software single step is still
used.  However, the underneath linux kernel does support hardware
single step, so IWBN to use it.

This patch is to add a new target_ops hook to_can_do_single_step, and
only use it in arm_linux_software_single_step to decide whether or not
to use hardware single step.  On the native aarch64 linux target, 1 is
returned.  On other targets, -1 is returned.  On the remote target, if
the target supports s and S actions in the vCont? reply, then target
can do single step.  However,  old GDBserver will send s and S in the
reply to vCont?, which will confuse new GDB.  For example, old GDBserver
on arm-linux will send s and S in the reply to vCont?, but it doesn't
support hardware single step.  On the other hand, new GDBserver, on
arm-linux for example, will not send s and S in the reply to vCont?,
but old GDB thinks it doesn't support vCont packet at all.  In order
to address this problem, I add a new qSupported feature vContSupported,
which indicates GDB wants to know the supported actions in the reply
to vCont?, and qSupported response contains vContSupported if the
stub is able tell supported vCont actions in the reply of vCont?.

If the patched GDB talks with patched GDBserver on x86, the RSP traffic
is like this:

 -> $qSupported:...+;vContSupported+
 <- ...+;vContSupported+
 ...
 -> $vCont?
 <- vCont;c;C;t;s;S;r

then, GDB knows the stub can do single step, and may stop using software
single step even the architecture doesn't support hardware single step.

If the patched GDB talks with patched GDBserver on arm, the last vCont?
reply will become:

 <- vCont;c;C;t

GDB thinks the target doesn't support single step, so it will use software
single step.

If the patched GDB talks with unpatched GDBserver, the RSP traffic is like
this:

 -> $qSupported:...+;vContSupported+
 <- ...+
 ...
 -> $vCont?
 <- vCont;c;C;t;s;S;r

although GDBserver returns s and S, GDB still thinks GDBserver may not
support single step because it doesn't support vContSupported.

If the unpatched GDB talks with patched GDBserver on x86, the RSP traffic
is like:

 -> $qSupported:...+;
 <- ...+;vContSupported+
 ...
 -> $vCont?
 <- vCont;c;C;t;s;S;r

Since GDB doesn't sent vContSupported in the qSupported feature, GDBserver
sends s and S regardless of the support of hardware single step.

gdb:

2015-09-15  Yao Qi  <yao.qi@linaro.org>

	* aarch64-linux-nat.c (aarch64_linux_can_do_single_step): New
	function.
	(_initialize_aarch64_linux_nat): Install it to to_can_do_single_step.
	* arm-linux-tdep.c (arm_linux_software_single_step): Return 0
	if target_can_do_single_step returns 1.
	* remote.c (struct vCont_action_support) <s, S>: New fields.
	(PACKET_vContSupported): New enum.
	(remote_protocol_features): New element for vContSupported.
	(remote_query_supported): Append "vContSupported+".
	(remote_vcont_probe): Remove support_s and support_S, use
	rs->supports_vCont.s and rs->supports_vCont.S instead.  Disable
	vCont packet if c and C actions are not supported.
	(remote_can_do_single_step): New function.
	(init_remote_ops): Install it to to_can_do_single_step.
	(_initialize_remote): Call add_packet_config_cmd.
	* target.h (struct target_ops) <to_can_do_single_step>: New field.
	(target_can_do_single_step): New macro.
	* target-delegates.c: Re-generated.

gdb/gdbserver:

2015-09-15  Yao Qi  <yao.qi@linaro.org>

	* server.c (vCont_supported): New global variable.
	(handle_query): Set vCont_supported to 1 if "vContSupported+"
	matches.  Append ";vContSupported+" to own_buf.
	(handle_v_requests): Append ";s;S" to own_buf if target supports
	hardware single step or vCont_supported is false.
	(capture_main): Set vCont_supported to zero.

gdb/doc:

2015-09-15  Yao Qi  <yao.qi@linaro.org>

	* gdb.texinfo (General Query Packets): Add vContSupported to
	tables of 'gdbfeatures' and 'stub features' supported in the
	qSupported packet, as well as to the list containing stub
	feature details.

2 files changed, 15 insertions, 0 deletions

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 1f99a2f..b5de969 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,10 @@
+2015-09-15  Yao Qi  <yao.qi@linaro.org>
+
+	* gdb.texinfo (General Query Packets): Add vContSupported to
+	tables of 'gdbfeatures' and 'stub features' supported in the
+	qSupported packet, as well as to the list containing stub
+	feature details.
+
 2015-09-11  Don Breazeal  <donb@codesourcery.com>
 
 	* gdb.texinfo (Remote Configuration): Add exec event
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 395f0d4..4ecdb8f 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -36132,6 +36132,10 @@ This feature indicates whether @value{GDBN} supports exec event
 extensions to the remote protocol.  @value{GDBN} does not use such
 extensions unless the stub also reports that it supports them by
 including @samp{exec-events+} in its @samp{qSupported} reply.
+
+@item vContSupported
+This feature indicates whether @value{GDBN} wants to know the
+supported actions in the reply to @samp{vCont?} packet.
 @end table
 
 Stubs should ignore any unknown values for
@@ -36608,6 +36612,10 @@ and vforkdone events.
 @item exec-events
 The remote stub reports the @samp{exec} stop reason for exec events.
 
+@item vContSupported
+The remote stub reports the supported actions in the reply to
+@samp{vCont?} packet.
+
 @end table
 
 @item qSymbol::